diff --git a/README.md b/README.md index 23553b50..8818600b 100644 --- a/README.md +++ b/README.md @@ -2,30 +2,17 @@ The Hedera Hashgraph API is implemented with protocol buffers, Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. This repository contains the current version of the files used to define the API. -## Structure - -The protobuf files are organised in folders representing the domain they pertain to, the folders are: - -- Common - messages that form part of the core API and are used within other messages -- Contract - messages related to the Hedera Hashgraph Smart Contract service -- Crypto - messages related to the Hedera Hashgraph Crypto Currency service -- File - messages related to the Hedera Hashgraph File service -- Query - messages related to querying the Hedera Hashgraph network -- Services - the gRPC definitions which detail which responses should be expected as a result of a request - ## Documentation The protobuf files themselves contain detailed comments which help understand not only the message itself but also some of the features and capabilities of the Hedera Hashgraph network. -Also available is a [HAPI.html](https://github.com/hashgraph/hedera-protobuf/blob/master/HAPI.html) document which is a HTML version of the protocol buffers file with hyperlinks to help navigate through the message definitions. It is also nested such that you can follow a complete message structure. +The `/docs` folder of this project contains automatically generated documents in html and markdown format to help navigate through the message definitions. -__Note__: the HAPI.html document is a large document and may take a few seconds to load in a browser. +[NestedDoc.html](https://github.com/hashgraph/hedera-protobuf/blob/master/docs/NestedDoc.html) - nested HTML document to help navigate messages that contain other message definitions (large document that takes a while to open) +[NotNestedDoc.html](https://github.com/hashgraph/hedera-protobuf/blob/master/docs/NotNestedDoc.html) - flat HTML document +[NotNestedDoc.md](https://github.com/hashgraph/hedera-protobuf/blob/master/docs/NotNestedDoc.md) - flat markdown document -## Examples - -Example messages can be found in the [Transaction-Query-Examples.md](https://github.com/hashgraph/hedera-protobuf/blob/master/Transaction-Query-Examples.md) file. These were generated with the [Hedera Hashgraph Java SDK](https://github.com/hashgraph/hedera-sdk-java) and may serve as a useful reference when checking if your own messages are correct. - -__Note__: The examples show keys and signatures. Keys shown in the examples are not the keys that were used to generate the signatures. +__Note__: the HAPI.html document is a large document and may take a few seconds to load in a browser. ## Additional resources @@ -44,8 +31,7 @@ If you are unfamiliar with protocol buffers (or need a refresher), you may consu ```shell cd docgenerator -java -jar proto2html.jar "HAPI Documentation" ../src/main/proto/ ../docs/NotNestedDoc N -java -jar proto2html.jar "HAPI Documentation" ../src/main/proto/ ../docs/NestedDoc Y +java -jar proto2html.jar "HAPI Documentation" ../src/main/proto/ ../docs ``` Commit all changes to github @@ -54,4 +40,4 @@ Commit all changes to github `mvn release:perform` -navigate to Nexus Repository Manager https://oss.sonatype.org/index.html#stagingRepositories and release the newly created repository. \ No newline at end of file +navigate to Nexus Repository Manager https://oss.sonatype.org/index.html#stagingRepositories and release the newly created repository. diff --git a/Transaction-Query-Examples.md b/Transaction-Query-Examples.md deleted file mode 100644 index ce14ce96..00000000 --- a/Transaction-Query-Examples.md +++ /dev/null @@ -1,1178 +0,0 @@ -# CRYPTO CREATE ACCOUNT - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538675158 - nanos: 77615000 - } - accountID { - accountNum: 1 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoCreateAccount { - key { - ed25519: "U\243\305d\311\006,/\376\342\274m\325e\026I\260r\262\256\345\353r\245z\374k\n\025%\221\241" - } - initialBalance: 10000 - autoRenewPeriod { - seconds: 2592000 - } - } -} -sigs { - sigs { - ed25519: "\336\354,&l\v\237\203N\217N\034\363\'S\n\212\021:\022r &\373\212\330\204\206\f \315\276\336\v\376M\222\241\265\375\360\343\025\353\\\361u\251#-2T\265\005\340\314\212\255\266&]\345\203\v" - } -} -``` - -# Get Receipt - -``` -transactionGetReceipt { - header { - } - transactionID { - transactionValidStart { - seconds: 1538675158 - nanos: 77615000 - } - accountID { - accountNum: 1 - } - } -} -``` - -# Get Receipt response -``` -transactionGetReceipt { - header { - cost: 2 - } - receipt { - } -} -``` - -# Get Receipt response -``` -transactionGetReceipt { - header { - cost: 2 - } - receipt { - status: SUCCESS - accountID { - accountNum: 1060 - } - } -} -``` - -# Get Receipt response -``` -transactionGetReceipt { - header { - nodeTransactionPrecheckCode: INVALID_TRANSACTION - cost: 2 - } -} -``` - -# Get Transaction Record -``` -transactionGetRecord { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538675161 - nanos: 749497000 - } - accountID { - accountNum: 1 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "\220m\227\347\354NS\330<\0330\002\3778\270\204E?\307\337(\230\205\346\241\250\314\277\213\332o~\3308\324\363\315o\355):\210e.\022\236\223\240\0202\270F/4\305\au\\\304~_%\223\016" - } - sigs { - ed25519: "\220m\227\347\354NS\330<\0330\002\3778\270\204E?\307\337(\230\205\346\241\250\314\277\213\332o~\3308\324\363\315o\355):\210e.\022\236\223\240\0202\270F/4\305\au\\\304~_%\223\016" - } - } - } - } - transactionID { - transactionValidStart { - seconds: 1538675158 - nanos: 77615000 - } - accountID { - accountNum: 1 - } - } -} -``` - -# Get Transaction Record Response -``` -transactionGetRecord { - header { - cost: 2 - } - transactionRecord { - receipt { - status: SUCCESS - accountID { - accountNum: 1060 - } - } - consensusTimestamp { - seconds: 1538675158 - nanos: 676511000 - } - transactionID { - transactionValidStart { - seconds: 1538675158 - nanos: 77615000 - } - accountID { - accountNum: 1 - } - } - memo: "Demo memo" - transactionFee: 10 - } -} -``` - -# Crypto Get Balance - -``` -cryptogetAccountBalance { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538726504 - nanos: 332518000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1038 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: ":v\'&\367\177c^c@\332\260\364\213\273\213~\360\034\324m\250O\241\363\200\b\030J\211\311\251\033\343\276\256\021\313\366B\343\r@L\337\024\242\001\256\037\332\030\252JS?s\271p\227\030\345\310\t" - } - sigs { - ed25519: ":v\'&\367\177c^c@\332\260\364\213\273\213~\360\034\324m\250O\241\363\200\b\030J\211\311\251\033\343\276\256\021\313\366B\343\r@L\337\024\242\001\256\037\332\030\252JS?s\271p\227\030\345\310\t" - } - } - } - } - accountID { - accountNum: 1038 - } -} -``` - -# Crypto Get Balance Response -``` -cryptogetAccountBalance { - header { - cost: 2 - } - accountID { - accountNum: 1038 - } - balance: 10000 -} -``` - -# Crypto Transfer -``` -body { - transactionID { - transactionValidStart { - seconds: 1538726504 - nanos: 385453000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1038 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 1039 - } - amount: 10 - } - } - } -} -sigs { - sigs { - ed25519: "Z\312yH\227\"\003\016a\022jd\274f\362h\rV\250\2534\212\245Stv\356\360n\215\255-j\177j\264Gm\333=\366\245KT\325\373^\301\274\"H++\361\302\2678\rs\2306hG\t" - } - sigs { - ed25519: "Z\312yH\227\"\003\016a\022jd\274f\362h\rV\250\2534\212\245Stv\356\360n\215\255-j\177j\264Gm\333=\366\245KT\325\373^\301\274\"H++\361\302\2678\rs\2306hG\t" - } -} -``` - -# Crypto Update Account -``` -body { - transactionID { - transactionValidStart { - seconds: 1538675161 - nanos: 775148000 - } - accountID { - accountNum: 1060 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoUpdateAccount { - accountIDToUpdate { - accountNum: 1060 - } - key { - ed25519: "w\251\210\224\123\024\204.\377=\244\000\2102&`\277N#\321\202t\037\337\330\360N\361\236\340@\271" - } - proxyAccountID { - accountNum: 1 - } - proxyFraction: 2 - sendRecordThreshold: 4000 - receiveRecordThreshold: 3000 - autoRenewPeriod { - seconds: 10 - nanos: 20 - } - expirationTime { - seconds: 200 - nanos: 100 - } - } -} -sigs { - sigs { - ed25519: "\224D\221\373$#\360P\3567W\321\330\202\035\026c\201\022@|\242{x#\311\224\366\323\340\324\304\210\363^\377\305~\\\022<%\335.l\036\272*4\250\177K\256Fj\305\343Hh\232\036\363\207\n" - } - sigs { - ed25519: "\224D\221\373$#\360P\3567W\321\330\202\035\026c\201\022@|\242{x#\311\224\366\323\340\324\304\210\363^\377\305~\\\022<%\335.l\036\272*4\250\177K\256Fj\305\343Hh\232\036\363\207\n" - } - sigs { - ed25519: "\262\006\225\a\306\204\\\004\203\202QZY\002\205\323,\206\024\2568hqk\375\343.L\201\312\376\321\005\2243\261\313\232*)\266 \357\330\242\217\031\024<\213\343\304\214\321\036\261(*/\337\371PM\a" - } -} -``` - -# Crypto Get Info - -``` -cryptoGetInfo { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538675165 - nanos: 844368000 - } - accountID { - accountNum: 1060 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1060 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "V\241V\270\310[@\362\247\223C\364c\364\026cO\230\313\204>R\210\a\023G6\002_\322\274\217X4;\211\350\250\001\370\306k\r\316\202\236\270\376\225\267j\200\270\032D\223l\v5\204\307\031\277\001" - } - sigs { - ed25519: "V\241V\270\310[@\362\247\223C\364c\364\026cO\230\313\204>R\210\a\023G6\002_\322\274\217X4;\211\350\250\001\370\306k\r\316\202\236\270\376\225\267j\200\270\032D\223l\v5\204\307\031\277\001" - } - } - } - } - accountID { - accountNum: 1060 - } -} -``` - -# Crypto Get info Response - -``` -cryptoGetInfo { - header { - cost: 2 - } - accountInfo { - accountID { - accountNum: 1060 - } - contractAccountID: "e020758a9fe6e7af19cf8a3c75debd1837f11523" - proxyAccountID { - } - proxyFraction: 2 - key { - ed25519: "77a98894cf14842edcf3da40088322660bf4e23d182741fdfd8f04ef19ee040b9" - } - balance: 10000 - generateSendRecordThreshold: 4000 - generateReceiveRecordThreshold: 3000 - expirationTime { - seconds: 200 - nanos: 100 - } - autoRenewPeriod { - seconds: 10 - nanos: 20 - } - } -} -``` - -# File Create - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538675747 - nanos: 123604000 - } - accountID { - accountNum: 1061 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - fileCreate { - expirationTime { - seconds: 1538762147 - nanos: 108871000 - } - keys { - keys { - ed25519: "F\247\350\143\"!f\305\016\232\354\202\213\020\314\032g5O\\-\246\372\t\340\364\331~T.\340-" - } - } - contents: "Creation contents" - } -} -sigs { - sigs { - ed25519: "\307\b\277\317v\226\016/\n+{\017\344\261\346OuU[\217p\265+J\267\333\232\200\355@\310\354\a\301\326\322#\253\234\265\270\302\211\004k\365-F\243\177\245\326\264\205[\222\374i\363\274\343\240h\t" - } - sigs { - signatureList { - sigs { - ed25519: "F\'}T\251m\v\337&V\301`6\210\335\244\351\342\201^\310r\306\207\265\351\004\343\017\241\334\324\375^\037<\263F\341S.\323\336\200\246\241\244[\263\270\314\210\244\324\365\354.Y\313%\232\372u\a" - } - } - } -} -``` - -# File Delete - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538675753 - nanos: 218623000 - } - accountID { - accountNum: 1061 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - fileDelete { - fileID { - fileNum: 1062 - } - } -} -sigs { - sigs { - ed25519: "}I7N\253\211j+\366#\177\233\001\227x\255\373T\205\023\222n\224x\345p?\346\337\336\v\'WZ\246I\332\341\024\020\203\231w\265\237\323\b\227\025\336\271\234\333\261\247\t\371ae\001\020\334\333\t" - } - sigs { - signatureList { - sigs { - ed25519: "N\351q\244+\242\215\321T\321\243\001\213q~\0371\320\337\306\276/\320\000\224\303\220\277\324\\\034N\002\234I\017\241\310\3642\344\341\221\226\a=\375\302\016\275\025x\240\177\235\037E\255\203Q\264\243\376\f" - } - } - } -} -``` - -# File Get Info - -``` -fileGetInfo { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538677345 - nanos: 636126000 - } - accountID { - accountNum: 1063 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1063 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "\322\340,\326\372y#\340m\265}.q.\033O\345\\\300\217m\261\'\225\314\232\024J\215\353{\344v\033G\025\371\275G\304\vvh\317\257\303tom\331\326G\017\205\305t\233\"\373[\a\026C\005" - } - sigs { - ed25519: "\322\340,\326\372y#\340m\265}.q.\033O\345\\\300\217m\261\'\225\314\232\024J\215\353{\344v\033G\025\371\275G\304\vvh\317\257\303tom\331\326G\017\205\305t\233\"\373[\a\026C\005" - } - } - } - } - fileID { - fileNum: 1064 - } -} -``` - -# File Get Info Response - -``` -fileGetInfo { - header { - cost: 2 - } - fileInfo { - fileID { - fileNum: 1064 - } - size: 17 - expirationTime { - seconds: 1538763741 - nanos: 561105000 - } - keys { - keys { - ed25519: "\233P\261\2155\tp-\a\244\361<\312\026\324\333i\016\245t>y5n\002g\222\263\317\303.v" - } - } - } -} -``` - -# File Append - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538677345 - nanos: 668697000 - } - accountID { - accountNum: 1063 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - fileAppend { - fileID { - fileNum: 1064 - } - contents: "Appended contents" - } -} -sigs { - sigs { - ed25519: "\374}\276-\355^\366\357\265\320\276\335h<t\204\222\370qbxU\a\233\303o\211\032\331\227PH\361\330\0017\221\373\b`l\232!\f%u\004<\253\ai*\247\200Y\3138ZysR\346\245\004" - } - sigs { - signatureList { - sigs { - ed25519: "\a\235\340r%NK\3361\375\3779/V\362\307\234\205\274\216\322\355\277\214\347:\262\341\355\226\210\035\324\023\b\024\024\272-\301\271\0312\272cu\aU\005A/\354\214v\224\326\354\005*\370:\324\321\016" - } - } - } -} -``` - -# File Get Contents - -``` -fileGetContents { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538677350 - nanos: 718802000 - } - accountID { - accountNum: 1063 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1063 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "sN\253\035\b[\002R\363\360\314\231!w\326\303\316\227G,\006\211\035\201I\301\262\377\360u,\234\352\342\005\305\024R\217\260A\342\306nF&\006\037b\305@\211\310:y2\025\211\352\377\362\352\340\004" - } - sigs { - ed25519: "sN\253\035\b[\002R\363\360\314\231!w\326\303\316\227G,\006\211\035\201I\301\262\377\360u,\234\352\342\005\305\024R\217\260A\342\306nF&\006\037b\305@\211\310:y2\025\211\352\377\362\352\340\004" - } - } - } - } - fileID { - fileNum: 1064 - } -} -``` - -# File Get Contents Response - -``` -fileGetContents { - header { - cost: 2 - } - fileContents { - fileID { - fileNum: 1064 - } - contents: "Creation contentsAppended contents" - } -} -``` - -# File Update - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538677350 - nanos: 745224000 - } - accountID { - accountNum: 1063 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "File Tests" - fileUpdate { - fileID { - fileNum: 1064 - } - expirationTime { - seconds: 1538677360 - nanos: 745210002 - } - contents: "Updated contents" - } -} -sigs { - sigs { - ed25519: "\362\271\275&\337L/We\212\264\333\241\216\350\341[q5\177=\b\341\343\260\255\rJvy\254\032\367\353d\251\230mn\037\376W\311~J\200\017\302\355J\0252\324\235\b\377\352\367\"\021H\365\337\016" - } - sigs { - signatureList { - sigs { - ed25519: "h\001/\327/DHq\362<\366\314\177\234M3\276\020\231\372\005\036%\241b\265\273T\253oU\252P\212\324\266\2274\023\034\346v\212\362\225\367@\344\235\277A\vf\276\006\034HG\302{\262S\317\v" - } - } - } -} -``` - -# Contract Create - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538677598 - nanos: 205222000 - } - accountID { - accountNum: 1065 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 100 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - contractCreateInstance { - fileID { - fileNum: 1066 - } - gas: 250000 - autoRenewPeriod { - seconds: 86400 - } - shardID { - } - realmID { - } - } -} -sigs { - sigs { - ed25519: "\323\004\373\307\020\224\371\373(`\v\217\221f\324\000\\X\351+D<\177\261\271^\253\030g${\251\264p\225\255\225\231\004 \031\310\365#!|3\321\004(\363\322\317\314\024\350\210\232\365\342\270\330\021\005" - } - sigs { - signatureList { - sigs { - ed25519: "\323\004\373\307\020\224\371\373(`\v\217\221f\324\000\\X\351+D<\177\261\271^\253\030g${\251\264p\225\255\225\231\004 \031\310\365#!|3\321\004(\363\322\317\314\024\350\210\232\365\342\270\330\021\005" - } - } - } -} -``` - -# Get receipt response - -``` -transactionGetReceipt { - header { - cost: 2 - } - receipt { - status: SUCCESS - contractID { - contractNum: 1040 - } - } -} -``` - -# Contract Update - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538677876 - nanos: 698746000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - contractUpdateInstance { - contractID { - contractNum: 1040 - } - expirationTime { - seconds: 100 - nanos: 10 - } - autoRenewPeriod { - seconds: 10 - nanos: 20 - } - } -} -sigs { - sigs { - ed25519: "\307\246\234\307\352<\352\325p5?o=\365\201\207\212\211\204\260\230\374\270~w\bN\276^-\341\'G?\330\354w)\231\005\217*8\347\260\206\027Y\352!\221\345\270I\201#\226\223\317\277:\0163\016" - } -} -``` - -# Contract Get Info - -``` -contractGetInfo { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538677879 - nanos: 758732000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1038 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: ")\353\201Z\333b]0\246}4\366t\n;/\306\334?U\256-\230\005\017a\003cL\3671U\365\357\005s\255\264\r\016\237o\264j\033\262\221#\366\316)\210Z\303\006\211=>\302\354\032\"\354\r" - } - sigs { - ed25519: ")\353\201Z\333b]0\246}4\366t\n;/\306\334?U\256-\230\005\017a\003cL\3671U\365\357\005s\255\264\r\016\237o\264j\033\262\221#\366\316)\210Z\303\006\211=>\302\354\032\"\354\r" - } - } - } - } - contractID { - contractNum: 1040 - } -} -``` - -# Contact Get Info Response - -``` -contractGetInfo { - header { - cost: 2 - } - contractInfo { - contractID { - contractNum: 1040 - } - accountID { - accountNum: 1040 - } - contractAccountID: "a1f32e6a59eb2fbaec2a75ce2b00f3fcd7489578" - expirationTime { - seconds: 100 - nanos: 10 - } - autoRenewPeriod { - seconds: 10 - nanos: 20 - } - storage: 344 - } -} -``` - -# Contract Get ByteCode - -``` -contractGetBytecode { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538677879 - nanos: 790702000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1038 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "SOO$\016e2AU\255P\356t\\\277\241\371M\201\361\332\371\312HkH\353\357\346\310$\351\305e\373\210FZol\230\314\344\005\324]\365(|\223\215\304\214\031\220\221Y\024\032\2213a\254\001" - } - sigs { - ed25519: "SOO$\016e2AU\255P\356t\\\277\241\371M\201\361\332\371\312HkH\353\357\346\310$\351\305e\373\210FZol\230\314\344\005\324]\365(|\223\215\304\214\031\220\221Y\024\032\2213a\254\001" - } - } - } - } - contractID { - contractNum: 1040 - } -} -``` - -# Contract Get ByteCode Response - -``` -contractGetBytecodeResponse { - header { - cost: 2 - } - bytecode: "```@R`\0046\020`HWc\377\377\377\377|\001\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000`\0005\004\026c`\376G\261\201\024`MW\200cmL\346<\024`bW[`\000\200\375[4\025`WW`\000\200\375[```\0045`\204V[\000[4\025`lW`\000\200\375[`r`\211V[`@Q\220\201R` \001`@Q\200\221\003\220\363[`\000UV[`\000T\220V\000\241ebzzr0X r\245\206J1\027\246\342\264\230\024\255X\255FIH\020|\204\365\354\r\260+\221\340\362jJ\017\314\000)" -} -``` - -# Contract Call - -``` -body { - transactionID { - transactionValidStart { - seconds: 1538677880 - nanos: 578038000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - contractCall { - contractID { - contractNum: 1040 - } - gas: 250000 - amount: 14 - functionParameters: "`\376G\261\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\n" - } -} -sigs { - sigs { - ed25519: "\313\335+9+[\n\312\344\203\225Wp\307\305<\323\321k\363\374A\260\005\351\276\227U\202c]x\324\v\332\3419\3234\316\n\001)9\353\313Fh\034\002\350\241\352\025\213\223P\317\332o\001\321\321\t" - } - sigs { - signatureList { - sigs { - ed25519: "\313\335+9+[\n\312\344\203\225Wp\307\305<\323\321k\363\374A\260\005\351\276\227U\202c]x\324\v\332\3419\3234\316\n\001)9\353\313Fh\034\002\350\241\352\025\213\223P\317\332o\001\321\321\t" - } - } - } -} -``` - -# Contract Run Local - -``` -contractCallLocal { - header { - payment { - body { - transactionID { - transactionValidStart { - seconds: 1538677884 - nanos: 664348000 - } - accountID { - accountNum: 1038 - } - } - nodeAccountID { - accountNum: 2 - } - transactionFee: 10 - transactionValidDuration { - seconds: 120 - } - generateRecord: true - memo: "Demo memo" - cryptoTransfer { - transfers { - accountAmounts { - accountID { - accountNum: 1038 - } - amount: -10 - } - accountAmounts { - accountID { - accountNum: 2 - } - amount: 10 - } - } - } - } - sigs { - sigs { - ed25519: "c Z\232\303!I\311\252\233}\350\372\261#\003\257M\016\037?Y\343H\220\304\314\020\376\215O\001k\202G\203\326\270\210\fh)\335\345\356\220\256\233\353\030\245\344\342I4\242\326e\201 \371\275\250\b" - } - sigs { - ed25519: "c Z\232\303!I\311\252\233}\350\372\261#\003\257M\016\037?Y\343H\220\304\314\020\376\215O\001k\202G\203\326\270\210\fh)\335\345\356\220\256\233\353\030\245\344\342I4\242\326e\201 \371\275\250\b" - } - } - } - } - contractID { - contractNum: 1040 - } - gas: 250000 - functionParameters: "mL\346<" - maxResultSize: 5000 -} -``` - -# Contract Run Local response - -``` -contractCallLocal { - header { - cost: 2 - } - functionResult { - contractID { - contractNum: 1040 - } - contractCallResult: "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\n" - } -} -``` diff --git a/docgenerator/proto2html.jar b/docgenerator/proto2html.jar index d4cf7481..f64472d3 100644 Binary files a/docgenerator/proto2html.jar and b/docgenerator/proto2html.jar differ diff --git a/docs/NestedDoc.html b/docs/NestedDoc.html index 1f706861..c4c35fc0 100644 --- a/docs/NestedDoc.html +++ b/docs/NestedDoc.html @@ -32,7 +32,7 @@ <li> <a href="#RealmID"><span class="badge">M</span>RealmID</a></li> <li> -<a href="#ServicesConfigurationLis"><span class="badge">M</span>ServicesConfigurationLis</a></li> +<a href="#ServicesConfigurationList"><span class="badge">M</span>ServicesConfigurationList</a></li> <li> <a href="#Setting"><span class="badge">M</span>Setting</a></li> <li> @@ -58,12 +58,20 @@ </ul> <a href=#ConsensusCreateTopic.proto>ConsensusCreateTopic.proto</a> <ul> +<li> +<a href="#ConsensusCreateTopicTransactionBody"><span class="badge">M</span>ConsensusCreateTopicTransactionBody</a></li> </ul> <a href=#ConsensusDeleteTopic.proto>ConsensusDeleteTopic.proto</a> <ul> +<li> +<a href="#ConsensusDeleteTopicTransactionBody"><span class="badge">M</span>ConsensusDeleteTopicTransactionBody</a></li> </ul> <a href=#ConsensusGetTopicInfo.proto>ConsensusGetTopicInfo.proto</a> <ul> +<li> +<a href="#ConsensusGetTopicInfoQuery"><span class="badge">M</span>ConsensusGetTopicInfoQuery</a></li> +<li> +<a href="#ConsensusGetTopicInfoResponse"><span class="badge">M</span>ConsensusGetTopicInfoResponse</a></li> </ul> <a href=#ConsensusService.proto>ConsensusService.proto</a> <ul> @@ -77,9 +85,13 @@ </ul> <a href=#ConsensusTopicInfo.proto>ConsensusTopicInfo.proto</a> <ul> +<li> +<a href="#ConsensusTopicInfo"><span class="badge">M</span>ConsensusTopicInfo</a></li> </ul> <a href=#ConsensusUpdateTopic.proto>ConsensusUpdateTopic.proto</a> <ul> +<li> +<a href="#ConsensusUpdateTopicTransactionBody"><span class="badge">M</span>ConsensusUpdateTopicTransactionBody</a></li> </ul> <a href=#ContractCall.proto>ContractCall.proto</a> <ul> @@ -402,6 +414,7 @@ <H2 id="BasicTypes.proto">BasicTypes.proto</H2> <a href="#title">Top</a> </div> +<P> 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.</P> <H3 id="AccountID"><span class="BigBadge">Message</span>AccountID</H3> <P> The ID for an a cryptocurrency account </P> <table class="field-table"> @@ -2905,7 +2918,7 @@ <H3 id="HederaFunctionality"><span class="BigBadge">Enum</span>HederaFunctionali </TABLE> <H3 id="Key"><span class="BigBadge">Message</span>Key</H3> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -3120,7 +3133,7 @@ <H3 id="KeyList"><span class="BigBadge">Message</span>KeyList</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -3398,7 +3411,7 @@ <H3 id="RealmID"><span class="BigBadge">Message</span>RealmID</H3> <tbody> </TABLE> -<H3 id="ServicesConfigurationLis"><span class="BigBadge">Message</span>ServicesConfigurationLis</H3> +<H3 id="ServicesConfigurationList"><span class="BigBadge">Message</span>ServicesConfigurationList</H3> <P></P> <table class="field-table"> <thead> @@ -3487,7 +3500,7 @@ <H3 id="Setting"><span class="BigBadge">Message</span>Setting</H3> </TABLE> <H3 id="ShardID"><span class="BigBadge">Message</span>ShardID</H3> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3507,7 +3520,7 @@ <H3 id="ShardID"><span class="BigBadge">Message</span>ShardID</H3> </TABLE> <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3574,7 +3587,7 @@ <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3599,7 +3612,7 @@ <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3646,7 +3659,7 @@ <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3685,7 +3698,7 @@ <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> </TABLE> <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3710,7 +3723,7 @@ <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3777,7 +3790,7 @@ <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -3833,7 +3846,7 @@ <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> </TABLE> <H3 id="SignatureMap"><span class="BigBadge">Message</span>SignatureMap</H3> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -3852,7 +3865,7 @@ <H3 id="SignatureMap"><span class="BigBadge">Message</span>SignatureMap</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -3921,7 +3934,7 @@ <H3 id="SignatureMap"><span class="BigBadge">Message</span>SignatureMap</H3> </TABLE> <H3 id="SignaturePair"><span class="BigBadge">Message</span>SignaturePair</H3> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -4029,7 +4042,7 @@ <H3 id="ThresholdKey"><span class="BigBadge">Message</span>ThresholdKey</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -4157,7 +4170,7 @@ <H3 id="ThresholdKey"><span class="BigBadge">Message</span>ThresholdKey</H3> </TABLE> <H3 id="ThresholdSignature"><span class="BigBadge">Message</span>ThresholdSignature</H3> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -4182,7 +4195,7 @@ <H3 id="ThresholdSignature"><span class="BigBadge">Message</span>ThresholdSignat <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -4207,7 +4220,7 @@ <H3 id="ThresholdSignature"><span class="BigBadge">Message</span>ThresholdSignat <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -4897,7 +4910,7 @@ <H3 id="TransactionID"><span class="BigBadge">Message</span>TransactionID</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -4973,58 +4986,8 @@ <H3 id="TransactionID"><span class="BigBadge">Message</span>TransactionID</H3> <H2 id="ConsensusCreateTopic.proto">ConsensusCreateTopic.proto</H2> <a href="#title">Top</a> </div> -<div class="file-heading"> -<H2 id="ConsensusDeleteTopic.proto">ConsensusDeleteTopic.proto</H2> -<a href="#title">Top</a> -</div> -<div class="file-heading"> -<H2 id="ConsensusGetTopicInfo.proto">ConsensusGetTopicInfo.proto</H2> -<a href="#title">Top</a> -</div> -<div class="file-heading"> -<H2 id="ConsensusService.proto">ConsensusService.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ConsensusService"><span class="BigBadge">Service</span>ConsensusService</H3> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>RPC</TD> -<TD>Request</TD> -<TD>Response</TD> -<TD>Comments</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>createTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> -</TR> - -<TR> -<TD>updateTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> -</TR> - -<TR> -<TD>deleteTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> -</TR> - -<TR> -<TD>getTopicInfo </TD><TD>Query</TD><TD>Response);</P></TD> -</TR> - -<TR> -<TD>submitMessage </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="ConsensusSubmitMessage.proto">ConsensusSubmitMessage.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ConsensusSubmitMessageTransactionBody"><span class="BigBadge">Message</span>ConsensusSubmitMessageTransactionBody</H3> +<P> See [ConsensusService.createTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusCreateTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusCreateTopicTransactionBody</H3> <P></P> <table class="field-table"> <thead> @@ -5036,15 +4999,21 @@ <H3 id="ConsensusSubmitMessageTransactionBody"><span class="BigBadge">Message</s </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -5055,51 +5024,14 @@ <H3 id="ConsensusSubmitMessageTransactionBody"><span class="BigBadge">Message</s </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="ConsensusTopicInfo.proto">ConsensusTopicInfo.proto</H2> -<a href="#title">Top</a> -</div> -<div class="file-heading"> -<H2 id="ConsensusUpdateTopic.proto">ConsensusUpdateTopic.proto</H2> -<a href="#title">Top</a> -</div> -<div class="file-heading"> -<H2 id="ContractCall.proto">ContractCall.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>ContractCallTransactionBody</H3> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<TD> </TD> +<TD colspan=2> <table class="field-table"> <thead> <TR> @@ -5112,7 +5044,7 @@ <H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>Contra <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -5152,32 +5084,33 @@ <H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>Contra </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> -<div class="file-heading"> -<H2 id="ContractCallLocal.proto">ContractCallLocal.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCallLocalQuery</H3> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.</P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -5188,15 +5121,21 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -5207,33 +5146,37 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -5244,34 +5187,39 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -5282,15 +5230,14 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -5301,32 +5248,466 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ConsensusDeleteTopic.proto">ConsensusDeleteTopic.proto</H2> +<a href="#title">Top</a> +</div> +<P> See [ConsensusService.deleteTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusDeleteTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusDeleteTopicTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ConsensusGetTopicInfo.proto">ConsensusGetTopicInfo.proto</H2> +<a href="#title">Top</a> +</div> +<P> See [ConsensusService.getTopicInfo()](#proto.ConsensusService)</P> +<H3 id="ConsensusGetTopicInfoQuery"><span class="BigBadge">Message</span>ConsensusGetTopicInfoQuery</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P> Standard info sent from client to node, including the signed payment, and what kind of response is requested<BR>(cost, state proof, both, or neither).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -5421,7 +5802,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5481,7 +5862,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5565,7 +5946,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5626,7 +6007,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -5886,7 +6267,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5922,7 +6303,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5988,7 +6369,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -6205,7 +6586,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -6266,7 +6647,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -6302,7 +6683,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -6550,7 +6931,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -6633,7 +7014,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -6803,7 +7184,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -6822,7 +7203,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -6908,7 +7289,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -7071,7 +7452,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7111,7 +7492,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7130,7 +7511,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -7402,7 +7783,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7432,7 +7813,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7498,7 +7879,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -7709,7 +8090,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7817,7 +8198,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -7927,7 +8308,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8009,7 +8390,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8070,7 +8451,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -8388,7 +8769,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8418,7 +8799,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8491,7 +8872,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8563,7 +8944,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8582,7 +8963,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8637,7 +9018,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -8806,7 +9187,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -8872,7 +9253,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -9083,7 +9464,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9149,7 +9530,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9210,7 +9591,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9265,7 +9646,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -9439,7 +9820,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9597,7 +9978,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9725,7 +10106,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -9771,27 +10152,258 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -9802,15 +10414,938 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -9878,7 +11413,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -9903,7 +11438,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -9970,7 +11505,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -10036,7 +11571,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -10055,7 +11590,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -10139,7 +11674,7 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -10179,15 +11714,15 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to retrieve info about (the parameters and running state of).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -10210,9 +11745,9 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -10220,29 +11755,11 @@ <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCal </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the amount of gas to use for the call. All of the gas offered will be charged for.</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - -<TR> -<TD>maxResultSize</TD> -<TD>int64</TD> -<TD><P>max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes.</P></TD> -</TR> - <tbody> </TABLE> -<H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>ContractCallLocalResponse</H3> -<P> Response when the client sends the node ContractCallLocalQuery </P> +<H3 id="ConsensusGetTopicInfoResponse"><span class="BigBadge">Message</span>ConsensusGetTopicInfoResponse</H3> +<P> Retrieve the parameters of and state of a consensus topic.</P> <table class="field-table"> <thead> <TR> @@ -10255,13 +11772,13 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract <TR> <TD>header</TD> <TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD><P> Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -10881,12 +12398,12 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -10903,7 +12420,7 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -10955,34 +12472,15 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract </TD> </TR> <TR> -<TD>functionResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>the value returned by the function (if it completed and didn't fail)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -11005,9 +12503,9 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -11016,39 +12514,52 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> +<TD>topicInfo</TD> +<TD><a href="#ConsensusTopicInfo">ConsensusTopicInfo</a></TD> +<TD><P>Current state of the topic</P></TD> </TR> <TR> -<TD>errorMessage</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> <TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>runningHash</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P> SHA-384 running hash <previousRunningHash, topicId, consensusTimestamp, sequenceNumber, message></P></TD> </TR> <TR> -<TD>gasUsed</TD> +<TD>sequenceNumber</TD> <TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD><P> Sequence number (starting at 1 for the first submitMessage) of messages on the topic.</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which submitMessage calls will no longer succeed on the topic<BR>and the topic will expire and after AUTORENEW_GRACE_PERIOD be automatically deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -11059,40 +12570,15 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -11101,57 +12587,15 @@ <H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>Contract </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFunctionResult</H3> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for update/delete of the topic. Null if there is no key.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -11162,62 +12606,14 @@ <H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFun </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> - -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> -</TR> - -<TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> <table class="field-table"> <thead> <TR> @@ -11230,7 +12626,7 @@ <H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFun <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -11270,33 +12666,33 @@ <H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFun </TD> </TR> <TR> -<TD>bloom</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>data</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>event data</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H3> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -11307,15 +12703,21 @@ <H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -11326,74 +12728,37 @@ <H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> -</TR> - <tbody> </TABLE> -<div class="file-heading"> -<H2 id="ContractCreate.proto">ContractCreate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>ContractCreateTransactionBody</H3> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -11404,38 +12769,39 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>Access control for ConsensusService.submitMessage. Null if there is no key.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -11633,21 +12999,39 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>initialBalance</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>proxyAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>Null if there is no autoRenewAccount.</P></TD> </TR> <TR> @@ -11686,16 +13070,79 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ConsensusService.proto">ConsensusService.proto</H2> +<a href="#title">Top</a> +</div> +<P> The Consensus Service provides the ability for Hedera Hashgraph to provide aBFT consensus as to the order and<BR>validity of messages submitted to a topic, as well as a consensus timestamp for those messages.<BR>Automatic renewal can be configured via an autoRenewAccount.<BR>Any time an autoRenewAccount is added to a topic, that createTopic/updateTopic transaction must be signed by<BR>the autoRenewAccount.<BR>The autoRenewPeriod on an account must currently be set a value in createTopic between MIN_AUTORENEW_PERIOD (6999999<BR>seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds). During creation this sets the initial expirationTime of the<BR>topic (see more below).<BR>If no adminKey is on a topic, there may not be an autoRenewAccount on the topic, deleteTopic is not allowed,<BR>and the only change allowed via an updateTopic is to extend the expirationTime.<BR>If an adminKey is on a topic, every updateTopic and deleteTopic transaction must be signed by the adminKey, except<BR>for updateTopics which only extend the topic's expirationTime (no adminKey authorization required).<BR>If an updateTopic modifies the adminKey of a topic, the transaction signatures on the updateTopic must fulfill both<BR>the pre-update and post-update adminKey signature requirements.<BR>Mirrornet ConsensusService may be used to subscribe to changes on the topic, including changes to the topic<BR>definition and the consensus ordering and timestamp of submitted messages.<BR>Until autoRenew functionality is supported by HAPI, the topic will not expire, the autoRenewAccount will not be<BR>charged, and the topic will not automatically be deleted.<BR>Once autoRenew functionality is supported by HAPI:<BR>1. Once the expirationTime is encountered, if an autoRenewAccount is configured on the topic, the account will be<BR>charged automatically at the expirationTime, to extend the expirationTime of the topic up to the topic's<BR>autoRenewPeriod (or as much extension as the account's balance will supply).<BR>2. If the topic expires and is not automatically renewed, the topic will enter the EXPIRED state. All transactions<BR>on the topic will fail with TOPIC_EXPIRED, except an updateTopic() call that modifies only the expirationTime.<BR>getTopicInfo() will succeed. This state will be available for a AUTORENEW_GRACE_PERIOD grace period (7 days).<BR>3. After the grace period, if the topic's expirationTime is not extended, the topic will be automatically<BR>deleted and no transactions or queries on the topic will succeed after that point.</P> +<H3 id="ConsensusService"><span class="BigBadge">Service</span>ConsensusService</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>RPC</TD> +<TD>Request</TD> +<TD>Response</TD> +<TD>Comments</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>createTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Create a topic to be used for consensus.<BR>If an autoRenewAccount is specified, that account must also sign this transaction.<BR>If an adminKey is specified, the adminKey must sign the transaction.<BR>On success, the resulting TransactionReceipt contains the newly created TopicId.<BR>Request is [ConsensusCreateTopicTransactionBody](#proto.ConsensusCreateTopicTransactionBody)</P></TD> +</TR> + +<TR> +<TD>updateTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Update a topic.<BR>If there is no adminKey, the only authorized update (available to anyone) is to extend the expirationTime.<BR>Otherwise transaction must be signed by the adminKey.<BR>If an adminKey is updated, the transaction must be signed by the pre-update adminKey and post-update adminKey.<BR>If a new autoRenewAccount is specified (not just being removed), that account must also sign the transaction.<BR>Request is [ConsensusUpdateTopicTransactionBody](#proto.ConsensusUpdateTopicTransactionBody)</P></TD> +</TR> + +<TR> +<TD>deleteTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Delete a topic. No more transactions or queries on the topic (via HAPI) will succeed.<BR>If an adminKey is set, this transaction must be signed by that key.<BR>If there is no adminKey, this transaction will fail UNAUTHORIZED.<BR>Request is [ConsensusDeleteTopicTransactionBody](#proto.ConsensusDeleteTopicTransactionBody)</P></TD> +</TR> + +<TR> +<TD>getTopicInfo </TD><TD>Query</TD><TD>Response</TD><TD><P> Retrieve the latest state of a topic. This method is unrestricted and allowed on any topic by any payer account.<BR>Deleted accounts will not be returned.<BR>Request is [ConsensusGetTopicInfoQuery](#proto.ConsensusGetTopicInfoQuery)<BR>Response is [ConsensusGetTopicInfoResponse](#proto.ConsensusGetTopicInfoResponse)</P></TD> +</TR> + +<TR> +<TD>submitMessage </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Submit a message for consensus.<BR>Valid and authorized messages on valid topics will be ordered by the consensus service, gossipped to the<BR>mirror net, and published (in order) to all subscribers (from the mirror net) on this topic.<BR>The submitKey (if any) must sign this transaction.<BR>On success, the resulting TransactionReceipt contains the topic's updated topicSequenceNumber and<BR>topicRunningHash.<BR>Request is [ConsensusSubmitMessageTransactionBody](#proto.ConsensusSubmitMessageTransactionBody)</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ConsensusSubmitMessage.proto">ConsensusSubmitMessage.proto</H2> +<a href="#title">Top</a> +</div> +<H3 id="ConsensusSubmitMessageTransactionBody"><span class="BigBadge">Message</span>ConsensusSubmitMessageTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -11706,9 +13153,21 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -11717,21 +13176,21 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> <TR> -<TD>constructorParameters</TD> +<TD>message</TD> <TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<div class="file-heading"> +<H2 id="ConsensusTopicInfo.proto">ConsensusTopicInfo.proto</H2> +<a href="#title">Top</a> +</div> +<P> Current state of a topic.</P> +<H3 id="ConsensusTopicInfo"><span class="BigBadge">Message</span>ConsensusTopicInfo</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -11742,26 +13201,33 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>runningHash</TD> +<TD>bytes</TD> +<TD><P> SHA-384 running hash <previousRunningHash, topicId, consensusTimestamp, sequenceNumber, message></P></TD> +</TR> -</TD> +<TR> +<TD>sequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Sequence number (starting at 1 for the first submitMessage) of messages on the topic.</P></TD> </TR> + <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which submitMessage calls will no longer succeed on the topic<BR>and the topic will expire and after AUTORENEW_GRACE_PERIOD be automatically deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -11772,15 +13238,15 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -11789,15 +13255,15 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>Access control for update/delete of the topic. Null if there is no key.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -11995,20 +13461,414 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for ConsensusService.submitMessage. Null if there is no key.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>Null if there is no autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + <div class="file-heading"> -<H2 id="ContractDelete.proto">ContractDelete.proto</H2> +<H2 id="ConsensusUpdateTopic.proto">ConsensusUpdateTopic.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>ContractDeleteTransactionBody</H3> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> All fields left null will not be updated.<BR>See [ConsensusService.updateTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusUpdateTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusUpdateTopicTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> <table class="field-table"> <thead> <TR> @@ -12021,7 +13881,7 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -12061,7 +13921,153 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -12079,9 +14085,208 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>transferAccountID</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -12120,10 +14325,29 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ContractCall.proto">ContractCall.proto</H2> +<a href="#title">Top</a> +</div> +<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.<BR>If this function stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee.</P> +<H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>ContractCallTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>transferContractID</TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -12162,17 +14386,34 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + <tbody> </TABLE> <div class="file-heading"> -<H2 id="ContractGetBytecode.proto">ContractGetBytecode.proto</H2> +<H2 id="ContractCallLocal.proto">ContractCallLocal.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractGetBytecodeQuery</H3> -<P> Get the bytecode for a smart contract instance </P> +<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCallLocalQuery</H3> +<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.<BR>This is performed locally on the particular node that the client is communicating with. It cannot change the state of the contract instance (and so, cannot spend anything from the instance's cryptocurrency account). It will not have a consensus timestamp. It cannot generate a record or a receipt. The response will contain the output returned by the function call. This is useful for calling getter functions, which purely read the state and don't change it. It is faster and cheaper than a normal call, because it is purely local to a single node.</P> <table class="field-table"> <thead> <TR> @@ -12185,7 +14426,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD>header</TD> <TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered.</P></TD> </TR> <TR> @@ -12210,7 +14451,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12247,7 +14488,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12285,7 +14526,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12416,7 +14657,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12476,7 +14717,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12560,7 +14801,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12621,7 +14862,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -12881,7 +15122,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12917,7 +15158,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -12983,7 +15224,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -13200,7 +15441,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -13261,7 +15502,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -13297,7 +15538,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -13545,7 +15786,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -13628,7 +15869,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -13798,7 +16039,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -13817,7 +16058,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -13903,7 +16144,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -14066,7 +16307,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14106,7 +16347,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14125,7 +16366,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -14397,7 +16638,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14427,7 +16668,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14493,7 +16734,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -14704,7 +16945,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14812,7 +17053,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -14922,7 +17163,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15004,7 +17245,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15065,7 +17306,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -15383,7 +17624,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15413,7 +17654,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15486,7 +17727,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15558,7 +17799,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15577,7 +17818,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15632,7 +17873,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -15801,7 +18042,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -15867,7 +18108,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -16078,7 +18319,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16144,7 +18385,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16205,7 +18446,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16260,7 +18501,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -16434,7 +18675,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16592,7 +18833,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16720,7 +18961,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -16766,27 +19007,258 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -16797,15 +19269,938 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -16873,7 +20268,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -16898,7 +20293,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -16965,7 +20360,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -17031,7 +20426,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -17050,7 +20445,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -17134,7 +20529,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -17176,7 +20571,7 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract for which information is requested</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -17215,11 +20610,29 @@ <H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractG </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the amount of gas to use for the call. All of the gas offered will be charged for.</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<TR> +<TD>maxResultSize</TD> +<TD>int64</TD> +<TD><P>max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes.</P></TD> +</TR> + <tbody> </TABLE> -<H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>ContractGetBytecodeResponse</H3> -<P> Response when the client sends the node ContractGetBytecodeQuery </P> +<H3 id="ContractCallLocalResponse"><span class="BigBadge">Message</span>ContractCallLocalResponse</H3> +<P> Response when the client sends the node ContractCallLocalQuery </P> <table class="field-table"> <thead> <TR> @@ -17238,7 +20651,7 @@ <H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>Contra <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -17858,12 +21271,12 @@ <H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>Contra <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -17880,7 +21293,7 @@ <H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>Contra <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -17932,20 +21345,15 @@ <H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>Contra </TD> </TR> <TR> -<TD>bytecode</TD> -<TD>bytes</TD> -<TD><P>the bytecode</P></TD> +<TD>functionResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>the value returned by the function (if it completed and didn't fail)</P></TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="ContractGetInfo.proto">ContractGetInfo.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetInfoQuery</H3> -<P> Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -17956,15 +21364,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -17975,33 +21383,62 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -18012,34 +21449,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -18050,34 +21468,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -18086,40 +21491,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> <tbody> @@ -18132,16 +21518,30 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> +<tbody> +</TABLE> + +<H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFunctionResult</H3> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -18164,9 +21564,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -18175,21 +21575,39 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>transactionFee</TD> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> <TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD><P>units of gas used to execute contract</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -18200,9 +21618,40 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -18211,45 +21660,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> <TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -18262,7 +21699,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> @@ -18302,38 +21739,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>data</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>event data</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<div class="file-heading"> +<H2 id="ContractCreate.proto">ContractCreate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.<BR>The instance will exist for autoRenewPeriod seconds. When that is reached, it will renew itself for another autoRenewPeriod seconds by charging its associated cryptocurrency account (which it creates here). If it has insufficient cryptocurrency to extend that long, it will extend as long as it can. If its balance is zero, the instance will be deleted.<BR>A smart contract instance normally enforces rules, so "the code is law". For example, an ERC-20 contract prevents a transfer from being undone without a signature by the recipient of the transfer. This is always enforced if the contract instance was created with the adminKeys being null. But for some uses, it might be desirable to create something like an ERC-20 contract that has a specific group of trusted individuals who can act as a "supreme court" with the ability to override the normal operation, when a sufficient number of them agree to do so. If adminKeys is not null, then they can sign a transaction that can change the state of the smart contract in arbitrary ways, such as to reverse a transaction that violates some standard of behavior that is not covered by the code itself. The admin keys can also be used to change the autoRenewPeriod, and change the adminKeys field itself. The API currently does not implement this ability. But it does allow the adminKeys field to be set and queried, and will in the future implement such admin abilities for any instance that has a non-null adminKeys.<BR>If this constructor stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee.<BR>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.<BR>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.<BR>The optional memo field can contain a string whose length is up to 100 bytes. That is the size after Unicode NFD then UTF-8 conversion. This field can be used to describe the smart contract. It could also be used for other purposes. One recommended purpose is to hold a hexadecimal string that is the SHA-384 hash of a PDF file containing a human-readable legal contract. Then, if the admin keys are the public keys of human arbitrators, they can use that legal document to guide their decisions during a binding arbitration tribunal, convened to consider any changes to the smart contract in the future. The memo field can only be changed using the admin keys. If there are no admin keys, then it cannot be changed after the smart contract is created.</P> +<H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>ContractCreateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -18394,7 +21826,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -18654,7 +22086,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -18690,7 +22122,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -18756,7 +22188,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -18962,18 +22394,13 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<div class="file-heading"> +<H2 id="ContractDelete.proto">ContractDelete.proto</H2> +<a href="#title">Top</a> +</div> +<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>ContractDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -18986,7 +22413,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> @@ -19026,15 +22453,14 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -19045,32 +22471,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -19081,27 +22490,32 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -19140,34 +22554,56 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ContractGetBytecode.proto">ContractGetBytecode.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the bytecode for a smart contract instance </P> +<H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractGetBytecodeQuery</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -19178,21 +22614,14 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -19203,37 +22632,34 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -19244,33 +22670,45 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -19307,18 +22745,23 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -19329,9 +22772,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -19340,15 +22795,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -19359,21 +22820,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -19381,27 +22830,46 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + <TR> <TD>memo</TD> <TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -19414,7 +22882,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -19454,33 +22922,38 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -19491,38 +22964,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -19545,33 +22995,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -19582,15 +23025,14 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> <table class="field-table"> <thead> <TR> @@ -19601,15 +23043,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -19632,9 +23074,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -19643,21 +23085,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>hash</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -19667,16 +23121,22 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> </thead> <tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + <TR> <TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -19687,33 +23147,37 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -19724,56 +23188,51 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -19784,62 +23243,74 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -19850,36 +23321,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -19890,15 +23351,32 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -20096,21 +23574,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -20121,56 +23604,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -20181,39 +23623,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -20222,15 +23646,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -20241,15 +23665,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -20258,15 +23682,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -20463,34 +23887,10 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>transferAccountID</TD> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -20530,15 +23930,45 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -20561,9 +23991,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -20571,21 +24001,27 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -20596,15 +24032,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -20627,20 +24063,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -20649,15 +24074,14 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -20668,15 +24092,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -20687,34 +24111,38 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -20737,9 +24165,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -20747,37 +24175,42 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -20788,9 +24221,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -20830,15 +24263,40 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -20957,25 +24415,6 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TD><P>List of all the keys that can sign</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -20985,11 +24424,6 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> @@ -20998,34 +24432,10 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TD><P>A list of Keys of the Key type.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -21035,63 +24445,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -21102,91 +24470,36 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> -<TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TD> </TR> - <tbody> </TABLE> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> -</TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -21197,31 +24510,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -21232,34 +24529,14 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> <table class="field-table"> <thead> <TR> @@ -21270,15 +24547,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -21301,9 +24578,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -21312,26 +24589,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>contents</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -21342,15 +24626,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -21361,26 +24651,31 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keys</TD> +<TD>keyList</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -21405,44 +24700,37 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -21465,9 +24753,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -21476,33 +24764,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -21513,68 +24801,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -21598,7 +24844,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -21640,7 +24886,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -21843,15 +25089,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -21862,15 +25108,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -21893,9 +25139,51 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -21909,15 +25197,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -21928,15 +25216,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -21959,9 +25247,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -21970,34 +25258,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> <tbody> @@ -22006,15 +25269,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -22025,15 +25288,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -22044,14 +25307,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -22062,15 +25326,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -22093,9 +25357,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -22104,33 +25368,36 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -22141,56 +25408,40 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -22199,15 +25450,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -22218,7 +25469,7 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -22236,15 +25487,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -22267,9 +25518,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -22278,15 +25529,33 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -22297,40 +25566,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -22341,11 +25591,17 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -22357,15 +25613,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -22376,33 +25632,39 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -22425,9 +25687,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -22436,15 +25698,20 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -22455,45 +25722,61 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> -</TD> +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> + <tbody> </TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -22504,27 +25787,45 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>endMin</TD> +<TD>nanos</TD> <TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -22533,27 +25834,46 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> @@ -22570,15 +25890,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -22601,9 +25921,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>topicNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -22612,41 +25932,45 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>message</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -22657,21 +25981,32 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -22682,13 +26017,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>signature</TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -22706,39 +26054,75 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -22749,15 +26133,15 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> @@ -22772,9 +26156,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -22796,15 +26180,21 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -22815,15 +26205,26 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -22834,13 +26235,43 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>signature</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -22858,34 +26289,119 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -22899,43 +26415,43 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> A list of keys </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> @@ -22947,15 +26463,34 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract for which information is requested</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -22978,9 +26513,9 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -22991,27 +26526,18 @@ <H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetIn <tbody> </TABLE> -<H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGetInfoResponse</H3> -<P> Response when the client sends the node ContractGetInfoQuery </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -23022,664 +26548,707 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a file </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TD> </TR> - <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> - <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TD> </TR> - <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> - <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -23688,32 +27257,33 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>stateProof</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>contractInfo</TD> -<TD><a href="#ContractGetInfoResponse.ContractInfo">ContractGetInfoResponse.ContractInfo</a></TD> -<TD><P>the information about this contract instance (a state proof can be generated for this)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractGetInfoQuery </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -23724,15 +27294,21 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>ID of the contract instance, in the format used in transactions</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -23743,38 +27319,37 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -23785,44 +27360,39 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> -</TR> - -<TR> -<TD>adminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -24020,15 +27590,15 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -24041,13 +27611,7 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -24056,15 +27620,15 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -24075,32 +27639,21 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>storage</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance, in tinybars</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -24111,8 +27664,18 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe <tbody> </TABLE> -<H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</span>ContractGetInfoResponse.ContractInfo</H3> -<P> Response when the client sends the node ContractGetInfoQuery </P> +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -24123,15 +27686,15 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>ID of the contract instance, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -24154,9 +27717,9 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -24165,15 +27728,21 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -24184,21 +27753,15 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -24206,22 +27769,16 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </TD> </TR> -<TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> -</TR> - <TR> <TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -24419,15 +27976,15 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -24438,32 +27995,33 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -24474,81 +28032,56 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>storage</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance, in tinybars</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="ContractGetRecords.proto">ContractGetRecords.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGetRecordsQuery</H3> -<P> Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -24559,14 +28092,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -24577,34 +28117,37 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -24615,51 +28158,39 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -24670,37 +28201,20 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -24739,63 +28253,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -24806,34 +28278,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -24856,9 +28309,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -24866,39 +28319,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -24909,15 +28344,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -24940,9 +28375,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -24951,15 +28386,41 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -24970,14 +28431,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -24988,15 +28456,20 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -25007,56 +28480,39 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -25067,34 +28523,32 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -25105,6 +28559,8 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -25114,15 +28570,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -25133,51 +28589,39 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -25188,104 +28632,104 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -25307,21 +28751,22 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>ContractGetBytecodeResponse</H3> +<P> Response when the client sends the node ContractGetBytecodeQuery </P> <table class="field-table"> <thead> <TR> @@ -25332,14 +28777,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -25350,727 +28796,621 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> -</TD> +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> + <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> + <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> + <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> -</TD> +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> + <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> + <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> -</TD> +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> + <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> + <TR> -<TD>obtainers</TD> -<TD>oneof</TD> +<TD>INVALID_ADMIN_KEY</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -26079,40 +29419,41 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -26120,23 +29461,39 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>bytecode</TD> +<TD>bytes</TD> +<TD><P>the bytecode</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ContractGetInfo.proto">ContractGetInfo.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. </P> +<H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -26147,15 +29504,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -26166,15 +29523,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -26185,44 +29542,33 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -26233,15 +29579,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -26252,14 +29598,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -26270,15 +29617,32 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -26301,9 +29665,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -26311,34 +29675,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -26349,62 +29700,123 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -26415,36 +29827,61 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -26455,15 +29892,57 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>key</TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -26660,16 +30139,22 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + <TR> <TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -26708,34 +30193,16 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -26756,16 +30223,22 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -26789,7 +30262,7 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -26825,13 +30298,13 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -27026,186 +30499,12 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -27214,53 +30513,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -27271,15 +30532,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -27302,66 +30563,26 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -27372,21 +30593,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -27395,15 +30610,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -27643,20 +30858,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -27667,28 +30877,26 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -27699,29 +30907,49 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -27732,26 +30960,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -27762,15 +30979,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -27779,7 +31002,7 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -27797,34 +31020,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -27835,15 +31039,38 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -27866,9 +31093,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -27876,27 +31103,23 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -27907,15 +31130,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -27926,15 +31149,40 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -27942,10 +31190,16 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -27970,7 +31224,7 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -28125,21 +31379,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28150,26 +31398,36 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28180,32 +31438,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -28400,42 +31641,24 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -28458,50 +31681,44 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28512,21 +31729,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -28535,15 +31740,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28554,15 +31759,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -28571,15 +31770,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -28590,15 +31789,32 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -28720,31 +31936,26 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -28752,27 +31963,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -28783,14 +31988,44 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -28801,15 +32036,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -28832,9 +32067,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -28843,15 +32078,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -28874,9 +32109,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -28886,16 +32121,19 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28906,9 +32144,40 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -28916,21 +32185,27 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -28941,14 +32216,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -28959,15 +32235,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -28978,38 +32254,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -29032,9 +32285,20 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -29044,21 +32308,24 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -29069,27 +32336,40 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -29098,33 +32378,33 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -29135,15 +32415,15 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -29166,9 +32446,9 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -29177,41 +32457,33 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -29222,21 +32494,21 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -29247,20 +32519,37 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -29271,39 +32560,39 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -29314,62 +32603,75 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> + <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> <table class="field-table"> <thead> <TR> @@ -29380,15 +32682,29 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -29399,20 +32715,26 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -29423,82 +32745,113 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - -<tbody> -</TABLE> +</thead> <tbody> -</TABLE> +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> -</TD> +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> + <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -29506,21 +32859,27 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract instance for which the records should be retrieved</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -29531,21 +32890,34 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -29553,11 +32925,16 @@ <H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGe </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +</TR> -<H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>ContractGetRecordsResponse</H3> -<P> Response when the client sends the node ContractGetRecordsQuery </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -29568,15 +32945,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -29587,621 +32964,781 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> - <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TD> </TR> - <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TD> </TR> - <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> <tbody> @@ -30210,58 +33747,77 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> + <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -30272,7 +33828,7 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract instance that this record is for</P></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> @@ -30311,16 +33867,18 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>records</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> -<TD><P>List of records, each with contractCreateResult or contractCallResult as its body</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -30331,15 +33889,31 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -30350,638 +33924,753 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> -</TR> - -<TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -30992,21 +34681,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -31015,15 +34698,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -31034,32 +34717,27 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -31099,15 +34777,33 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -31118,15 +34814,21 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -31137,27 +34839,37 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -31168,11 +34880,17 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -31180,19 +34898,21 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -31203,27 +34923,14 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -31234,36 +34941,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -31286,9 +34972,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -31297,38 +34983,58 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> + <TR> -<TD>transactionHash</TD> -<TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -31339,32 +35045,37 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -31375,15 +35086,39 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -31396,13 +35131,7 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -31411,9 +35140,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>accountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -31458,26 +35187,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> -</TR> - -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> -</TR> - -<TR> -<TD>body</TD> -<TD>oneof</TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -31488,34 +35206,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -31538,9 +35237,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -31548,40 +35247,21 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> -<TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +</TD> </TR> - <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -31592,15 +35272,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -31623,9 +35303,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -31634,21 +35314,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> +<TD>message</TD> <TD>bytes</TD> -<TD><P>event data</P></TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> <tbody> @@ -31658,19 +35326,29 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -31681,15 +35359,21 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -31700,81 +35384,63 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCallResult</TD> +<TD>contract</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -31785,46 +35451,42 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> @@ -31835,18 +35497,16 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -31857,15 +35517,15 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -31876,15 +35536,20 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -31895,39 +35560,31 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> @@ -31941,73 +35598,66 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac <tbody> </TABLE> -<div class="file-heading"> -<H2 id="ContractUpdate.proto">ContractUpdate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>ContractUpdateTransactionBody</H3> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -32018,15 +35668,21 @@ <H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -32034,16 +35690,11 @@ <H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>Cont </TD> </TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGetInfoResponse</H3> +<P> Response when the client sends the node ContractGetInfoQuery </P> <table class="field-table"> <thead> <TR> @@ -32054,14 +35705,15 @@ <H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -32072,744 +35724,664 @@ <H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>Cont </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> -</TD> +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> + <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> -</TD> +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> -<div class="file-heading"> -<H2 id="CryptoAddClaim.proto">CryptoAddClaim.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="Claim"><span class="BigBadge">Message</span>Claim</H3> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> + <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> -</TD> +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> + <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> -</TD> +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>CryptoAddClaimTransactionBody</H3> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> -</TD> +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> + <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> -</thead> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -32818,33 +36390,32 @@ <H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>Cryp </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> +<TD>stateProof</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> </TR> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractInfo</TD> +<TD><a href="#ContractGetInfoResponse.ContractInfo">ContractGetInfoResponse.ContractInfo</a></TD> +<TD><P>the information about this contract instance (a state proof can be generated for this)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -32855,62 +36426,57 @@ <H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>ID of the contract instance, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -32921,49 +36487,44 @@ <H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoCreate.proto">CryptoCreate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>CryptoCreateTransactionBody</H3> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -33161,21 +36722,15 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33186,21 +36741,15 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -33208,34 +36757,16 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33257,15 +36788,52 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>storage</TD> +<TD>int64</TD> +<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance, in tinybars</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</span>ContractGetInfoResponse.ContractInfo</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>ID of the contract instance, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -33278,7 +36846,19 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -33287,15 +36867,15 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -33317,21 +36897,33 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -33528,34 +37120,16 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoDelete.proto">CryptoDelete.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteTransactionBody</H3> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33566,21 +37140,15 @@ <H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -33589,15 +37157,15 @@ <H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33608,37 +37176,44 @@ <H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>realmNum</TD> +<TD>storage</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance, in tinybars</P></TD> </TR> + <tbody> </TABLE> <div class="file-heading"> -<H2 id="CryptoDeleteClaim.proto">CryptoDeleteClaim.proto</H2> +<H2 id="ContractGetRecords.proto">ContractGetRecords.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteClaimTransactionBody</H3> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P> Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. </P> +<H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGetRecordsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -33649,15 +37224,15 @@ <H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>C </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -33668,94 +37243,28 @@ <H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>C </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoGetAccountBalance.proto">CryptoGetAccountBalance.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>CryptoGetAccountBalanceQuery</H3> -<P> Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> @@ -33779,7 +37288,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33817,7 +37326,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -33948,7 +37457,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34008,7 +37517,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34092,7 +37601,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34153,7 +37662,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -34413,7 +37922,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34449,7 +37958,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34515,7 +38024,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -34732,7 +38241,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34793,7 +38302,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -34829,7 +38338,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -35077,7 +38586,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35160,7 +38669,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35330,7 +38839,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -35349,7 +38858,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35435,7 +38944,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -35598,7 +39107,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35638,7 +39147,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35657,7 +39166,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -35929,7 +39438,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -35959,7 +39468,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36025,7 +39534,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -36236,7 +39745,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36344,7 +39853,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36454,7 +39963,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36536,7 +40045,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36597,7 +40106,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -36915,7 +40424,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -36945,7 +40454,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37018,7 +40527,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37090,7 +40599,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37109,7 +40618,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37164,7 +40673,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -37333,7 +40842,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37399,7 +40908,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -37610,7 +41119,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37676,7 +41185,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37737,7 +41246,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -37792,7 +41301,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -37966,7 +41475,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -38124,7 +41633,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -38252,7 +41761,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -38298,27 +41807,258 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -38329,15 +42069,938 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -38405,7 +43068,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -38430,7 +43093,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -38497,7 +43160,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -38563,7 +43226,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -38582,7 +43245,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -38666,7 +43329,7 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -38703,72 +43366,12 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>balanceSource</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> +<TD><P>The smart contract instance for which the records should be retrieved</P></TD> </TR> <TR> @@ -38809,11 +43412,9 @@ <H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>Crypt </TR> <tbody> </TABLE> -<tbody> -</TABLE> -<H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>CryptoGetAccountBalanceResponse</H3> -<P> Response when the client sends the node CryptoGetAccountBalanceQuery </P> +<H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>ContractGetRecordsResponse</H3> +<P> Response when the client sends the node ContractGetRecordsQuery </P> <table class="field-table"> <thead> <TR> @@ -38832,7 +43433,7 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -39452,12 +44053,12 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -39474,7 +44075,7 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -39526,15 +44127,15 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that is being described (this is useful with state proofs, for proving to a third party)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The smart contract instance that this record is for</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -39557,9 +44158,9 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -39568,20 +44169,15 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance, in tinybars</P></TD> +<TD>records</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> +<TD><P>List of records, each with contractCreateResult or contractCallResult as its body</P></TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoGetAccountRecords.proto">CryptoGetAccountRecords.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>CryptoGetAccountRecordsQuery</H3> -<P> Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -39592,15 +44188,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -39611,735 +44207,621 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> + <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> -</TD> +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> + <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> + <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> -</TD> +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> + <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> <TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> + <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> -</TD> +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> + <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> -</TD> +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> + <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> -</TD> +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> + <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> + <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -40348,15 +44830,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -40378,21 +44860,27 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -40403,27 +44891,32 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> </TR> <TR> @@ -40463,33 +44956,34 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -40500,21 +44994,27 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -40525,17 +45025,11 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -40547,15 +45041,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -40566,17 +45060,42 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> + <tbody> </TABLE> @@ -40584,51 +45103,24 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -40651,9 +45143,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -40662,15 +45154,38 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>expirationTime</TD> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -40698,15 +45213,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -40717,14 +45232,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -40735,7 +45251,686 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>contractID</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +</TR> + +<TR> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ContractUpdate.proto">ContractUpdate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>ContractUpdateTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> <TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> @@ -40954,7 +46149,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -41026,18 +46221,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<div class="file-heading"> +<H2 id="CryptoAddClaim.proto">CryptoAddClaim.proto</H2> +<a href="#title">Top</a> +</div> +<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<H3 id="Claim"><span class="BigBadge">Message</span>Claim</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -41048,15 +46238,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -41079,9 +46269,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -41090,7 +46280,51 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -41108,15 +46342,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -41139,9 +46373,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -41150,15 +46384,33 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -41169,45 +46421,87 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>CryptoAddClaimTransactionBody</H3> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -41226,7 +46520,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -41312,7 +46606,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -41475,7 +46769,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -41504,18 +46798,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<div class="file-heading"> +<H2 id="CryptoCreate.proto">CryptoCreate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.<BR>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.<BR>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.</P> +<H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>CryptoCreateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -41534,7 +46823,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -41806,7 +47095,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -41836,7 +47125,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -41902,7 +47191,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -42102,18 +47391,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> +<div class="file-heading"> +<H2 id="CryptoDelete.proto">CryptoDelete.proto</H2> +<a href="#title">Top</a> +</div> <P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -42210,18 +47494,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> +<div class="file-heading"> +<H2 id="CryptoDeleteClaim.proto">CryptoDeleteClaim.proto</H2> +<a href="#title">Top</a> +</div> <P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteClaimTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -42282,18 +47561,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<div class="file-heading"> +<H2 id="CryptoGetAccountBalance.proto">CryptoGetAccountBalance.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. </P> +<H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>CryptoGetAccountBalanceQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -42304,15 +47578,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -42323,15 +47597,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -42342,15 +47616,14 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -42361,59 +47634,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -42424,15 +47653,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -42443,38 +47672,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -42485,33 +47691,32 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -42534,9 +47739,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -42544,34 +47749,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -42582,21 +47774,44 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -42607,37 +47822,37 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> -</TD> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -42648,39 +47863,34 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -42703,9 +47913,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -42714,52 +47924,38 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -42770,29 +47966,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -42803,45 +47985,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -42850,14 +48008,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -42868,34 +48027,14 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> <table class="field-table"> <thead> <TR> @@ -42906,15 +48045,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -42937,9 +48076,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -42948,26 +48087,33 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>contents</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -42978,15 +48124,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -42997,26 +48149,31 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keys</TD> +<TD>keyList</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -43041,44 +48198,43 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -43101,9 +48257,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -43112,33 +48268,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -43149,68 +48287,32 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> +<TD>constructorParameters</TD> <TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -43234,7 +48336,7 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -43270,13 +48372,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -43473,87 +48575,27 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -43564,15 +48606,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -43595,9 +48637,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -43608,13 +48650,13 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -43642,34 +48684,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -43791,31 +48814,26 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -43823,27 +48841,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -43854,33 +48866,39 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -43903,9 +48921,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -43914,15 +48932,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -43933,21 +48951,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -43955,18 +48961,16 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -43977,9 +48981,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -43987,21 +49003,27 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -44012,7 +49034,49 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>id</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -44030,15 +49094,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -44061,9 +49125,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -44072,9 +49136,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>contractID</TD> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -44121,15 +49185,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -44140,56 +49204,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> @@ -44206,15 +49223,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -44237,9 +49254,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -44248,41 +49265,40 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>message</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -44293,21 +49309,14 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -44318,20 +49327,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -44342,39 +49346,56 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -44385,15 +49406,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> @@ -44408,9 +49429,9 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -44432,15 +49453,15 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -44451,15 +49472,36 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -44470,13 +49512,26 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>signature</TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -44494,34 +49549,119 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -44535,43 +49675,36 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> A list of keys </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -44579,13 +49712,21 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which the records should be retrieved</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -44624,11 +49765,34 @@ <H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>Crypt </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -<H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>CryptoGetAccountRecordsResponse</H3> -<P> Response when the client sends the node CryptoGetAccountRecordsQuery </P> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -44639,15 +49803,26 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -44658,692 +49833,834 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> 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. </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> - <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +</TD> </TR> - <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> A list of keys </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account that this record is for</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -45383,15 +50700,20 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>records</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> -<TD><P>List of records, each with CryptoRecordBody as their body</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> <table class="field-table"> <thead> <TR> @@ -45402,15 +50724,28 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> <table class="field-table"> <thead> <TR> @@ -45421,638 +50756,743 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -<TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TD> </TR> - <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TD> </TR> - <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -46075,9 +51515,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -46085,10 +51525,34 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> @@ -46128,15 +51592,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> -</TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -46147,21 +51611,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -46170,15 +51628,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -46189,15 +51647,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -46208,27 +51666,14 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -46239,31 +51684,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -46274,40 +51703,21 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -46315,26 +51725,34 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -46345,61 +51763,73 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionHash</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -46410,32 +51840,14 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -46446,15 +51858,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -46465,15 +51877,21 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -46482,15 +51900,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -46513,9 +51931,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -46525,30 +51943,51 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <tbody> </TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -46559,15 +51998,14 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -46578,15 +52016,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -46609,9 +52047,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -46620,52 +52058,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> - -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> -</TR> - -<TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -46702,24 +52097,56 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -46727,21 +52154,59 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> -</TD> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> + <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -46754,7 +52219,7 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -46794,39 +52259,33 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -46837,15 +52296,21 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -46856,46 +52321,58 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -46903,21 +52380,21 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -46928,15 +52405,14 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -46947,15 +52423,15 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -46978,9 +52454,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -46989,54 +52465,33 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<div class="file-heading"> -<H2 id="CryptoGetClaim.proto">CryptoGetClaim.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaimQuery</H3> -<P> Get a single claim attached to an account, or return null if it does not exist. </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -47047,15 +52502,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -47066,33 +52527,37 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -47103,34 +52568,39 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -47143,13 +52613,7 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -47158,9 +52622,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>accountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> @@ -47205,15 +52669,34 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -47236,9 +52719,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -47247,21 +52730,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -47274,7 +52757,13 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -47283,26 +52772,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -47313,15 +52791,14 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> <table class="field-table"> <thead> <TR> @@ -47334,7 +52811,7 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -47374,38 +52851,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -47416,15 +52888,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -47435,38 +52913,80 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -47664,21 +53184,39 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>initialBalance</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>proxyAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -47717,52 +53255,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -47773,26 +53280,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -47814,21 +53310,32 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -47839,33 +53346,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -47888,9 +53377,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -47899,120 +53388,11 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> +<TD>message</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -48026,45 +53406,23 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> -<TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -48075,38 +53433,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -48117,43 +53458,13 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>signature</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -48171,75 +53482,39 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -48250,34 +53525,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> @@ -48291,34 +53547,10 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -48329,26 +53561,26 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -48359,38 +53591,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -48401,26 +53610,20 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -48431,102 +53634,96 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>balanceSource</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -48544,9 +53741,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>transferAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P>The account ID for which information is requested</P></TD> </TR> <TR> @@ -48586,9 +53783,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>transferContractID</TD> +<TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD><P>The account ID for which information is requested</P></TD> </TR> <TR> @@ -48632,18 +53829,8 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>CryptoGetAccountBalanceResponse</H3> +<P> Response when the client sends the node CryptoGetAccountBalanceQuery </P> <table class="field-table"> <thead> <TR> @@ -48654,15 +53841,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -48673,655 +53860,621 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> -</TD> +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> + <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> -</TD> +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> + <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> -</TD> +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> + <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -49330,52 +54483,75 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> -</thead> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that is being described (this is useful with state proofs, for proving to a third party)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -49398,9 +54574,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -49409,33 +54585,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance, in tinybars</P></TD> </TR> -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> +<div class="file-heading"> +<H2 id="CryptoGetAccountRecords.proto">CryptoGetAccountRecords.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. </P> +<H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>CryptoGetAccountRecordsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -49446,21 +54610,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -49471,37 +54629,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -49512,44 +54666,34 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -49560,15 +54704,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -49579,21 +54723,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -49602,9 +54740,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>deleteAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -49649,28 +54787,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> +<TD>nodeAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> @@ -49710,26 +54829,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -49740,15 +54854,37 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -49759,15 +54895,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -49778,15 +54914,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -49809,9 +54945,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -49820,36 +54956,38 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -49860,15 +54998,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -49891,9 +55029,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -49902,15 +55040,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -50107,10 +55245,22 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -50150,20 +55300,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -50174,28 +55319,32 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -50206,29 +55355,26 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -50239,9 +55385,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -50250,15 +55402,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -50269,31 +55421,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -50304,34 +55458,56 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -50342,15 +55518,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -50361,32 +55543,74 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -50395,15 +55619,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -50414,15 +55638,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -50433,15 +55657,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -50450,15 +55680,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -50469,15 +55699,32 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -50599,18 +55846,20 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -50621,8 +55870,6 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -50632,21 +55879,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -50657,26 +55898,39 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -50698,21 +55952,27 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -50723,33 +55983,26 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -50772,9 +56025,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -50783,33 +56036,26 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -50820,21 +56066,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -50845,37 +56085,37 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -50886,63 +56126,57 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -50965,9 +56199,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -50977,19 +56211,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -51000,15 +56236,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -51019,38 +56255,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -51061,15 +56274,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -51077,10 +56296,16 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -51105,7 +56330,7 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -51260,26 +56485,55 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -51290,14 +56544,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -51308,15 +56563,14 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -51327,32 +56581,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -51391,18 +56622,59 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -51413,11 +56685,17 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -51429,15 +56707,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -51448,33 +56726,45 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -51497,9 +56787,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -51508,15 +56798,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -51527,45 +56835,56 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -51576,27 +56895,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -51605,33 +56912,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -51642,15 +56949,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -51673,9 +56980,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -51684,41 +56991,33 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -51729,21 +57028,21 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -51754,63 +57053,37 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -51821,15 +57094,9 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -51841,18 +57108,6 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference </TD> </TR> <tbody> @@ -51868,15 +57123,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -51887,15 +57142,15 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -51906,20 +57161,38 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -51930,36 +57203,23 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <tbody> </TABLE> @@ -51971,57 +57231,28 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> +<TD>accountIDToDeleteFrom</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID to which the claim was attached</P></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> @@ -52061,16 +57292,26 @@ <H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaim </TD> </TR> <TR> -<TD>hash</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>The hash of the claim</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> <tbody> </TABLE> -<H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetClaimResponse</H3> -<P> Response when the client sends the node CryptoGetClaimQuery. If the claim exists, there can be a state proof for that single claim. If the claim doesn't exist, then the state proof must be obtained for the account as a whole, which lists all the attached claims, which then proves that any claim not on the list must not exist. </P> +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -52081,15 +57322,15 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -52100,664 +57341,623 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +</TD> </TR> - <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - -<TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> - -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> - -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> - -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a file </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -52766,15 +57966,9 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> <tbody> @@ -52783,15 +57977,15 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </TD> </TR> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>The claim (account, hash, keys), or null if there is no Claim with the given hash attached to the given account</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -52802,15 +57996,15 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -52821,21 +58015,15 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -52843,16 +58031,10 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -52877,7 +58059,7 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -53032,15 +58214,21 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -53051,9 +58239,9 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -53061,39 +58249,16 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoGetInfo.proto">CryptoGetInfo.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQuery</H3> -<P> Get all the information about an account, including the balance. This does not get the list of account records. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -53104,33 +58269,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -53141,15 +58305,14 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> <table class="field-table"> <thead> <TR> @@ -53160,15 +58323,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -53179,34 +58342,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -53215,15 +58365,33 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -53234,43 +58402,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -53281,44 +58427,37 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -53329,56 +58468,44 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -53389,15 +58516,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -53420,9 +58547,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -53430,39 +58557,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -53475,7 +58584,7 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> @@ -53515,15 +58624,70 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -53645,20 +58809,18 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -53669,6 +58831,8 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -53678,15 +58842,26 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -53697,51 +58872,33 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - +<table class="field-table"> +<thead> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -53764,9 +58921,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -53775,15 +58932,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -53794,45 +58951,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -53840,16 +58973,18 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -53860,32 +58995,31 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -53896,7 +59030,7 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>key</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -53914,15 +59048,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -53945,9 +59079,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -53956,33 +59090,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -53993,83 +59109,23 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -54083,26 +59139,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -54113,40 +59158,27 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -54155,15 +59187,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -54174,32 +59206,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -54397,15 +59418,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -54416,38 +59437,14 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -54458,26 +59455,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -54500,9 +59486,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -54511,26 +59497,33 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -54541,15 +59534,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -54560,37 +59559,37 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -54601,15 +59600,39 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -54620,21 +59643,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -54643,15 +59654,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -54674,9 +59685,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -54686,40 +59697,19 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -54730,15 +59720,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -54761,9 +59751,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -54772,21 +59762,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -54797,15 +59787,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -54927,18 +59934,20 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -54949,8 +59958,6 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -54960,15 +59967,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -54979,14 +59986,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> -<tbody> -</TABLE> - +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -54996,38 +60004,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -55224,82 +60215,16 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -55321,15 +60246,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -55342,43 +60267,19 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -55386,34 +60287,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -55424,15 +60312,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -55455,9 +60343,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -55465,34 +60353,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -55503,21 +60378,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -55528,58 +60397,34 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -55592,21 +60437,24 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -55617,15 +60465,21 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -55636,38 +60490,20 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -55678,43 +60514,39 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -55725,68 +60557,62 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -55797,15 +60623,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -55816,34 +60642,20 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -55854,34 +60666,31 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> +<tbody> +</TABLE> <tbody> </TABLE> @@ -55898,28 +60707,57 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD><P>The account ID for which the records should be retrieved</P></TD> </TR> <TR> @@ -55958,16 +60796,11 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>CryptoGetAccountRecordsResponse</H3> +<P> Response when the client sends the node CryptoGetAccountRecordsQuery </P> <table class="field-table"> <thead> <TR> @@ -55978,14 +60811,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -55996,727 +60830,664 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> + <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> -</TD> +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> + <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> -</TD> +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> + <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> -</TD> +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> + <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> -</TD> +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> + <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> -<table class="field-table"> -<thead> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> -</TD> +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> + <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> -</TD> +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> + <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> + <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> -</TD> +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> + <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -56725,15 +61496,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account that this record is for</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -56755,21 +61543,27 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>records</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> +<TD><P>List of records, each with CryptoRecordBody as their body</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -56780,14 +61574,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -56798,703 +61593,638 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> -</TD> +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> + <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> + <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> -</TD> +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> -<tbody> -</TABLE> + <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> -</TD> +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -57505,27 +62235,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD><P>The file ID, if a new file was created</P></TD> </TR> <TR> @@ -57567,7 +62302,7 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> </TR> <TR> @@ -57606,23 +62341,35 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -57633,62 +62380,93 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>startHour</TD> +<TD>hbarEquiv</TD> <TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD><P>value which denote habar equivalent to cent</P></TD> </TR> <TR> -<TD>startMin</TD> +<TD>centEquiv</TD> <TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -57699,9 +62477,30 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> <TD>topicID</TD> <TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> </TR> <TR> @@ -57741,41 +62540,38 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> -<tbody> -</TABLE> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>bodyBytes</TD> +<TD>transactionHash</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -57786,21 +62582,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -57811,20 +62618,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -57835,39 +62637,32 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -57878,62 +62673,54 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> -</TD> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> </TR> + <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> <table class="field-table"> <thead> <TR> @@ -57944,15 +62731,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -57963,20 +62750,15 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -57987,82 +62769,129 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>ECDSA_384</TD> +<TD>contractCallResult</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD><P>the result returned by the function</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> -</TD> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> + <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> <tbody> @@ -58076,15 +62905,34 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -58107,9 +62955,9 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -58117,30 +62965,40 @@ <H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQu </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> -<H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInfoResponse</H3> -<P> Response when the client sends the node CryptoGetInfoQuery </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -58151,698 +63009,492 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<div class="file-heading"> +<H2 id="CryptoGetClaim.proto">CryptoGetClaim.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get a single claim attached to an account, or return null if it does not exist. </P> +<H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaimQuery</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - -<TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - -<TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> - -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - -<TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> - -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> - -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> - -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> - -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - -<TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - -<TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TD> </TR> - <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> +<TD>data</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountInfo</TD> -<TD><a href="#CryptoGetInfoResponse.AccountInfo">CryptoGetInfoResponse.AccountInfo</a></TD> -<TD><P>Info about the account (a state proof can be generated for this)</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetInfoQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -58853,15 +63505,15 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which this information applies</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -58884,9 +63536,9 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -58895,27 +63547,57 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TD> </TR> <TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID of the account to which this 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.</P></TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -58938,9 +63620,9 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -58949,21 +63631,15 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TD> </TR> <TR> -<TD>proxyReceived</TD> -<TD>int64</TD> -<TD><P>The total number of tinybars proxy staked to this account</P></TD> -</TR> - -<TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -59161,39 +63837,27 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance of account in tinybars</P></TD> -</TR> - -<TR> -<TD>generateSendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> -</TR> - -<TR> -<TD>generateReceiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The TimeStamp time at which this account is set to expire</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -59204,15 +63868,21 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -59223,13 +63893,13 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -59251,15 +63921,21 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TD> </TR> <TR> -<TD>claims</TD> -<TD><a href="#Claim">Claim</a> (repeated)</TD> -<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -59270,15 +63946,26 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -59300,52 +63987,21 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -59467,18 +64123,20 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -59489,8 +64147,6 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -59500,15 +64156,15 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -59519,11 +64175,17 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -59531,19 +64193,32 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +</TR> -<H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span>CryptoGetInfoResponse.AccountInfo</H3> -<P> Response when the client sends the node CryptoGetInfoQuery </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -59554,15 +64229,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which this information applies</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -59585,9 +64260,9 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -59596,27 +64271,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> -</TR> - -<TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID of the account to which this 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.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -59627,21 +64290,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -59650,21 +64307,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>proxyReceived</TD> -<TD>int64</TD> -<TD><P>The total number of tinybars proxy staked to this account</P></TD> -</TR> - -<TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -59862,39 +64513,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance of account in tinybars</P></TD> -</TR> - -<TR> -<TD>generateSendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> -</TR> - -<TR> -<TD>generateReceiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The TimeStamp time at which this account is set to expire</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -59905,15 +64532,21 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -59924,13 +64557,13 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -59952,34 +64585,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>claims</TD> -<TD><a href="#Claim">Claim</a> (repeated)</TD> -<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -60002,9 +64616,9 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -60013,21 +64627,26 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -60038,15 +64657,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -60057,7 +64676,30 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -60075,15 +64717,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -60106,9 +64748,9 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -60117,33 +64759,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -60154,62 +64778,45 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -60220,30 +64827,15 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> -<tbody> -</TABLE> -<div class="file-heading"> -<H2 id="CryptoGetStakers.proto">CryptoGetStakers.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H3> -<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -60256,7 +64848,7 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is being proxy staked to</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -60296,15 +64888,21 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H </TD> </TR> <TR> -<TD>proxyStaker</TD> -<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> -<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> information about a single account that is proxy staking </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -60315,15 +64913,52 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is proxy staking</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -60346,9 +64981,9 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -60357,40 +64992,33 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H </TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>The number of hbars that are currently proxy staked</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetStakersQuery</H3> -<P> Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -60401,33 +65029,62 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -60438,15 +65095,36 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -60457,15 +65135,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -60476,15 +65154,14 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -60495,32 +65172,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -60543,9 +65203,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -60553,21 +65213,34 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -60578,44 +65251,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -60626,37 +65276,37 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TD> </TR> - <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -60667,34 +65317,45 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -60717,9 +65378,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -60728,21 +65389,46 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -60751,15 +65437,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -60770,15 +65456,26 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -60800,27 +65497,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -61017,28 +65708,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TD> </TR> - <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -61049,38 +65733,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -61091,45 +65752,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -61138,15 +65775,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -61168,39 +65805,32 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -61211,15 +65841,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -61242,9 +65872,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -61253,33 +65883,26 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -61290,21 +65913,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -61315,37 +65932,34 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -61356,50 +65970,59 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -61410,15 +66033,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -61441,45 +66064,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -61488,15 +66075,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -61736,15 +66323,20 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -61755,26 +66347,28 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -61785,49 +66379,29 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -61838,15 +66412,26 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -61857,21 +66442,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -61880,7 +66459,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -61898,15 +66477,34 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -61917,38 +66515,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -61971,9 +66546,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -61981,42 +66556,27 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62027,15 +66587,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62046,21 +66606,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -62068,16 +66622,10 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -62102,7 +66650,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -62257,15 +66805,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62276,9 +66830,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -62286,26 +66840,16 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -62316,15 +66860,32 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -62519,24 +67080,42 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -62559,9 +67138,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -62569,34 +67148,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62607,26 +67173,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -62639,7 +67194,19 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -62648,15 +67215,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62667,15 +67234,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -62684,15 +67251,34 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -62814,20 +67400,18 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -62838,6 +67422,8 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -62847,15 +67433,26 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -62866,44 +67463,14 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> <table class="field-table"> <thead> <TR> @@ -62914,15 +67481,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -62945,9 +67512,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -62956,15 +67523,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -62987,9 +67554,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -62999,38 +67566,16 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -63041,21 +67586,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -63063,27 +67596,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63094,15 +67621,14 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -63113,15 +67639,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -63132,15 +67658,38 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -63163,20 +67712,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -63186,24 +67724,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63214,15 +67749,44 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63233,38 +67797,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -63462,15 +68009,52 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -63493,9 +68077,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -63504,20 +68088,33 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -63528,28 +68125,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -63560,29 +68150,37 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -63593,26 +68191,39 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63625,13 +68236,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -63640,14 +68245,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -63658,34 +68264,43 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63696,15 +68311,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -63727,20 +68342,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -63749,34 +68353,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -63804,34 +68395,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -63953,18 +68525,20 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -63975,8 +68549,6 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -63986,21 +68558,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -64011,62 +68577,39 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -64261,23 +68804,18 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -64288,15 +68826,26 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -64319,9 +68868,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -64335,15 +68884,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -64354,15 +68903,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -64385,26 +68934,31 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -64415,15 +68969,40 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -64432,34 +69011,41 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> -</thead> + <tbody> +</TABLE> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -64470,14 +69056,21 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -64488,15 +69081,20 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -64507,56 +69105,39 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -64567,15 +69148,15 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> @@ -64590,617 +69171,9 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> -</TR> - -<TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -65230,7 +69203,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -65249,7 +69222,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -65333,7 +69306,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -65375,7 +69348,7 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for which the records should be retrieved</P></TD> +<TD><P>The account ID to which the claim was attached</P></TD> </TR> <TR> @@ -65414,11 +69387,17 @@ <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetSta </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>The hash of the claim</P></TD> +</TR> + <tbody> </TABLE> -<H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGetStakersResponse</H3> -<P> Response when the client sends the node CryptoGetStakersQuery </P> +<H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetClaimResponse</H3> +<P> Response when the client sends the node CryptoGetClaimQuery. If the claim exists, there can be a state proof for that single claim. If the claim doesn't exist, then the state proof must be obtained for the account as a whole, which lists all the attached claims, which then proves that any claim not on the list must not exist. </P> <table class="field-table"> <thead> <TR> @@ -65437,7 +69416,7 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66057,12 +70036,12 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -66079,7 +70058,7 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -66131,15 +70110,15 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet </TD> </TR> <TR> -<TD>stakers</TD> -<TD><a href="#AllProxyStakers">AllProxyStakers</a></TD> -<TD><P>List of accounts proxy staking to this account, and the amount each is currently proxy staking</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>The claim (account, hash, keys), or null if there is no Claim with the given hash attached to the given account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66152,7 +70131,7 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is being proxy staked to</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -66192,15 +70171,21 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet </TD> </TR> <TR> -<TD>proxyStaker</TD> -<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> -<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> information about a single account that is proxy staking </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -66211,15 +70196,15 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is proxy staking</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -66230,49 +70215,14 @@ <H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGet </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>The number of hbars that are currently proxy staked</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> -<P> information about a single account that is proxy staking </P> +<TD> </TD> +<TD colspan=2> <table class="field-table"> <thead> <TR> @@ -66283,15 +70233,15 @@ <H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is proxy staking</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -66314,9 +70264,9 @@ <H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -66325,114 +70275,99 @@ <H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>The number of hbars that are currently proxy staked</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoService.proto">CryptoService.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoService"><span class="BigBadge">Service</span>CryptoService</H3> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>RPC</TD> -<TD>Request</TD> -<TD>Response</TD> -<TD>Comments</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>createAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> -</TR> - -<TR> -<TD>updateAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates an account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>cryptoTransfer </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>cryptoDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>addClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>deleteClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>getClaim </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the claim for an account by submitting the query.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>getAccountRecords </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the record(fetch by AccountID ID) for an account by submitting the query.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>cryptoGetBalance </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the balance for an account by submitting the query.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>getAccountInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the account information for an account by submitting the query.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>getTransactionReceipts </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee.</P></TD> +</TD> </TR> - <TR> -<TD>getFastTransactionRecord </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transaction record by TxID which last for 180sec only for no fee.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>getTxRecordByTxID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>getStakersByAccountID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the stakers for a node by account ID by submitting the query.</P></TD> +</TD> </TR> - <tbody> </TABLE> -<div class="file-heading"> -<H2 id="CryptoTransfer.proto">CryptoTransfer.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="AccountAmount"><span class="BigBadge">Message</span>AccountAmount</H3> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66443,39 +70378,31 @@ <H3 id="AccountAmount"><span class="BigBadge">Message</span>AccountAmount</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - <tbody> </TABLE> -<H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>CryptoTransferTransactionBody</H3> -<P> 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 to do the withdrawal, 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. </P> +<div class="file-heading"> +<H2 id="CryptoGetInfo.proto">CryptoGetInfo.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get all the information about an account, including the balance. This does not get the list of account records. </P> +<H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -66486,15 +70413,15 @@ <H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -66505,15 +70432,15 @@ <H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66524,15 +70451,14 @@ <H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -66543,49 +70469,34 @@ <H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>Cryp </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -66596,15 +70507,15 @@ <H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66615,9 +70526,26 @@ <H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> </thead> <tbody> <TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -66656,39 +70584,15 @@ <H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> </TD> </TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="CryptoUpdate.proto">CryptoUpdate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>CryptoUpdateTransactionBody</H3> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>accountIDToUpdate</TD> +<TD>nodeAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> @@ -66728,15 +70632,21 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66747,7 +70657,30 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>key</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -66765,15 +70698,34 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -66807,33 +70759,38 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -66844,21 +70801,15 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -66869,37 +70820,38 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -66910,39 +70862,33 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -66965,9 +70911,9 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -66976,52 +70922,33 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -67032,29 +70959,21 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -67065,61 +70984,37 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -67130,83 +71025,51 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - -<tbody> -</TABLE> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="Duration.proto">Duration.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="Duration"><span class="BigBadge">Message</span>Duration</H3> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - +</TABLE> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="ExchangeRate.proto">ExchangeRate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ExchangeRate"><span class="BigBadge">Message</span>ExchangeRate</H3> -<P> Values from these proto denotes habr and cents(USD) conversion </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -67217,71 +71080,38 @@ <H3 id="ExchangeRate"><span class="BigBadge">Message</span>ExchangeRate</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H3> -<P> Two sets of exchange rate </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> +</TABLE> -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TD> </TR> - <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -67294,60 +71124,30 @@ <H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -67358,9 +71158,9 @@ <H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -67368,39 +71168,16 @@ <H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="FileAppend.proto">FileAppend.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppendTransactionBody</H3> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -67422,106 +71199,21 @@ <H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppe <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="FileCreate.proto">FileCreate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCreateTransactionBody</H3> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -67640,6 +71332,25 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -67649,6 +71360,11 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -67657,10 +71373,34 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> Self Reference +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <tbody> @@ -67670,27 +71410,46 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -67703,7 +71462,19 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -67712,15 +71483,15 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -67731,15 +71502,15 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -67748,15 +71519,15 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -67953,34 +71724,16 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea </TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="FileDelete.proto">FileDelete.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDeleteTransactionBody</H3> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -68003,9 +71756,9 @@ <H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDele </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -68013,15 +71766,16 @@ <H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDele </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> -<div class="file-heading"> -<H2 id="FileGetContents.proto">FileGetContents.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetContentsQuery</H3> -<P> Get the contents of a file. The content field is empty (no bytes) if the file is empty. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -68032,15 +71786,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -68051,33 +71816,49 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -68088,15 +71869,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -68107,34 +71888,37 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -68145,26 +71929,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -68201,23 +71968,18 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -68240,9 +72002,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -68250,63 +72012,23 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -68317,15 +72039,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -68336,15 +72058,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -68367,9 +72089,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -68378,57 +72100,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -68439,38 +72125,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -68592,20 +72255,18 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -68616,6 +72277,8 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -68625,112 +72288,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> +<TD>claimDuration</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -68751,52 +72317,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -68807,32 +72347,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -69030,26 +72553,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -69060,15 +72578,56 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -69079,21 +72638,39 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>contractNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -69102,15 +72679,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -69121,15 +72698,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -69138,15 +72715,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -69341,12 +72918,36 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -69386,45 +72987,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -69447,9 +73018,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -69457,27 +73028,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -69488,15 +73053,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -69519,9 +73084,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -69530,14 +73095,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -69548,15 +73125,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -69567,38 +73144,34 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -69621,9 +73194,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -69631,42 +73204,37 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -69677,9 +73245,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>accountIDToUpdate</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> @@ -69719,40 +73287,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -69871,6 +73414,25 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -69880,6 +73442,11 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -69888,6 +73455,25 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -69896,26 +73482,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -69926,9 +73512,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -69936,26 +73534,86 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> + <tbody> </TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -69966,15 +73624,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -69985,7 +73654,24 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>key</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -70003,15 +73689,53 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -70034,9 +73758,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -70045,33 +73769,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70082,21 +73799,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70107,31 +73818,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> +<TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -70156,37 +73862,44 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -70209,9 +73922,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -70220,33 +73933,33 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -70257,26 +73970,68 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70300,7 +74055,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -70342,7 +74097,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -70545,34 +74300,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70583,38 +74319,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -70637,9 +74350,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -70653,15 +74366,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70672,15 +74385,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -70703,9 +74416,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -70714,9 +74427,34 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -70725,15 +74463,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -70744,15 +74482,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -70763,15 +74501,14 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -70782,15 +74519,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -70813,9 +74550,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -70824,36 +74561,33 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -70864,40 +74598,56 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> <tbody> @@ -70906,15 +74656,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -70925,7 +74675,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>key</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -70943,15 +74693,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -70974,9 +74724,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -70985,33 +74735,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -71022,21 +74754,40 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -71047,17 +74798,11 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -71069,15 +74814,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -71088,39 +74833,33 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -71143,218 +74882,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -71377,9 +74924,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -71387,27 +74934,23 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -71418,34 +74961,27 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>nanos</TD> +<TD>endMin</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -71454,15 +74990,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -71473,15 +75009,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -71603,18 +75145,20 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -71625,8 +75169,6 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -71636,21 +75178,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -71661,62 +75197,39 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -71911,23 +75424,18 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -71938,15 +75446,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -71969,9 +75488,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -71985,15 +75504,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -72004,15 +75523,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -72035,9 +75554,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -72045,16 +75564,22 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -72082,34 +75607,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -72228,6 +75734,25 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -72237,6 +75762,11 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -72248,14 +75778,26 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -72263,27 +75805,23 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -72294,7 +75832,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -72312,15 +75850,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -72343,9 +75881,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -72354,15 +75892,33 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -72373,40 +75929,21 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -72417,11 +75954,17 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -72433,15 +75976,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -72452,33 +75995,39 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -72489,21 +76038,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -72512,15 +76049,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -72543,9 +76080,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -72555,21 +76092,19 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -72580,27 +76115,40 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -72608,24 +76156,11 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +</TD> </TR> - <TR> <TD>consensusSubmitMessage</TD> <TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> @@ -72722,7 +76257,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -72747,7 +76282,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -72814,7 +76349,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -72880,7 +76415,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -72899,7 +76434,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -72983,7 +76518,7 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -73023,15 +76558,15 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file whose contents are requested</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -73054,9 +76589,9 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -73067,8 +76602,8 @@ <H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetConten <tbody> </TABLE> -<H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetContentsResponse</H3> -<P> Response when the client sends the node FileGetContentsQuery </P> +<H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInfoResponse</H3> +<P> Response when the client sends the node CryptoGetInfoQuery </P> <table class="field-table"> <thead> <TR> @@ -73087,7 +76622,7 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -73707,12 +77242,12 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -73729,7 +77264,7 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -73781,15 +77316,15 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon </TD> </TR> <TR> -<TD>fileContents</TD> -<TD><a href="#FileGetContentsResponse.FileContents">FileGetContentsResponse.FileContents</a></TD> -<TD><P>the file ID and contents (a state proof can be generated for this)</P></TD> +<TD>accountInfo</TD> +<TD><a href="#CryptoGetInfoResponse.AccountInfo">CryptoGetInfoResponse.AccountInfo</a></TD> +<TD><P>Info about the account (a state proof can be generated for this)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node FileGetContentsQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -73800,15 +77335,15 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file whose contents are being returned</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID for which this information applies</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -73831,9 +77366,9 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -73842,40 +77377,27 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes contained in the file</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> </TR> -<tbody> -</TABLE> -<H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</span>FileGetContentsResponse.FileContents</H3> -<P> Response when the client sends the node FileGetContentsQuery </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file whose contents are being returned</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID of the account to which this 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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -73898,9 +77420,9 @@ <H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</sp </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -73909,20 +77431,21 @@ <H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</sp </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes contained in the file</P></TD> +<TD>proxyReceived</TD> +<TD>int64</TD> +<TD><P>The total number of tinybars proxy staked to this account</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> +</TR> -<div class="file-heading"> -<H2 id="FileGetInfo.proto">FileGetInfo.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery</H3> -<P> Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -73933,15 +77456,14 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -73952,15 +77474,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -73971,14 +77493,56 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -73989,15 +77553,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -74008,15 +77578,37 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -74027,15 +77619,63 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>transactionValidStart</TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance of account in tinybars</P></TD> +</TR> + +<TR> +<TD>generateSendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> +</TR> + +<TR> +<TD>generateReceiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD><P>The TimeStamp time at which this account is set to expire</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -74063,110 +77703,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> +<TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -74188,45 +77733,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>claims</TD> +<TD><a href="#Claim">Claim</a> (repeated)</TD> +<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -74237,15 +77752,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -74268,9 +77783,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -74279,57 +77794,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -74340,38 +77819,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -74493,20 +77949,18 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -74517,6 +77971,8 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -74526,15 +77982,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -74545,17 +78001,11 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -74563,27 +78013,32 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> +<tbody> +</TABLE> +<H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span>CryptoGetInfoResponse.AccountInfo</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID for which this information applies</P></TD> </TR> <TR> @@ -74623,51 +78078,27 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID of the account to which this 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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -74680,43 +78111,19 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -74725,15 +78132,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>proxyReceived</TD> +<TD>int64</TD> +<TD><P>The total number of tinybars proxy staked to this account</P></TD> +</TR> + +<TR> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -74931,9 +78344,58 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance of account in tinybars</P></TD> +</TR> + +<TR> +<TD>generateSendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> +</TR> + +<TR> +<TD>generateReceiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The TimeStamp time at which this account is set to expire</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -74942,15 +78404,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -74961,15 +78423,45 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claims</TD> +<TD><a href="#Claim">Claim</a> (repeated)</TD> +<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -74992,9 +78484,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -75003,15 +78495,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -75022,32 +78520,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -75169,20 +78650,18 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -75193,6 +78672,8 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -75202,15 +78683,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -75221,17 +78702,11 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -75239,15 +78714,32 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> -</TD> +<div class="file-heading"> +<H2 id="CryptoGetStakers.proto">CryptoGetStakers.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. </P> +<H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H3> +<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The Account ID that is being proxy staked to</P></TD> </TR> <TR> @@ -75287,15 +78779,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyStaker</TD> +<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> +<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> information about a single account that is proxy staking </P> <table class="field-table"> <thead> <TR> @@ -75306,26 +78798,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that is proxy staking</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -75348,9 +78829,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -75359,9 +78840,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>The number of hbars that are currently proxy staked</P></TD> </TR> <tbody> @@ -75369,16 +78850,30 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<tbody> +</TABLE> + +<H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetStakersQuery</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -75389,15 +78884,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -75408,37 +78903,33 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -75449,15 +78940,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -75468,21 +78959,34 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -75491,15 +78995,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -75522,9 +79026,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -75534,53 +79038,13 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> +<TD>nodeAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> @@ -75620,21 +79084,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -75645,15 +79109,37 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -75664,14 +79150,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -75684,7 +79171,7 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -75724,33 +79211,38 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -75761,62 +79253,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -75827,55 +79272,38 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -76072,16 +79500,22 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + <TR> <TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -76120,34 +79554,16 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -76168,16 +79584,22 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -76201,7 +79623,7 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -76237,13 +79659,13 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -76438,186 +79860,12 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -76626,53 +79874,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -76683,15 +79893,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -76714,66 +79924,26 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -76784,21 +79954,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -76807,15 +79971,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -77055,20 +80219,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -77079,28 +80238,26 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -77111,29 +80268,49 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77144,26 +80321,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -77174,15 +80340,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -77191,7 +80363,7 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -77209,34 +80381,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -77247,15 +80400,38 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -77278,9 +80454,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -77288,27 +80464,23 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -77319,15 +80491,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77338,15 +80510,40 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -77354,10 +80551,16 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -77382,7 +80585,7 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -77537,21 +80740,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77562,26 +80759,36 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77592,32 +80799,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -77812,42 +81002,24 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -77870,50 +81042,44 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77924,21 +81090,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -77947,15 +81101,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -77966,15 +81120,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -77983,15 +81131,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -78002,15 +81150,32 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -78132,31 +81297,26 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -78164,27 +81324,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -78195,14 +81349,44 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -78213,15 +81397,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -78244,9 +81428,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -78255,15 +81439,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -78286,9 +81470,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -78298,16 +81482,19 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -78318,9 +81505,40 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -78328,21 +81546,27 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -78353,14 +81577,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -78371,15 +81596,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -78390,38 +81615,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -78444,9 +81646,20 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -78456,21 +81669,24 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -78481,27 +81697,40 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -78510,33 +81739,33 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -78547,15 +81776,15 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -78578,9 +81807,9 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -78589,41 +81818,33 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -78634,21 +81855,21 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -78659,20 +81880,37 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -78683,39 +81921,39 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -78726,62 +81964,75 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> + <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> <table class="field-table"> <thead> <TR> @@ -78792,15 +82043,29 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -78811,20 +82076,26 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -78835,98 +82106,82 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file for which information is requested</P></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> @@ -78965,30 +82220,27 @@ <H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery< </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> -<H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoResponse</H3> -<P> Response when the client sends the node FileGetInfoQuery </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -78999,765 +82251,643 @@ <H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoRes </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +</TD> </TR> - <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> -</TR> - -<TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> -<thead> -<TR> -<TD>Enum Name</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileInfo</TD> -<TD><a href="#FileGetInfoResponse.FileInfo">FileGetInfoResponse.FileInfo</a></TD> -<TD><P>The information about the file (a state proof can be generated for this)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Response when the client sends the node FileGetInfoQuery </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file for which information is requested</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>size</TD> -<TD>int64</TD> -<TD><P>Number of bytes in contents</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The current time at which this account is set to expire</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -79784,16 +82914,10 @@ <H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoRes </TD> </TR> -<TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>True if deleted but not yet expired</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> @@ -79818,7 +82942,7 @@ <H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoRes <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -79972,16 +83096,45 @@ <H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoRes </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -<H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileGetInfoResponse.FileInfo</H3> -<P> Response when the client sends the node FileGetInfoQuery </P> +<TR> +<TD> </TD> +<TD colspan=2> <table class="field-table"> <thead> <TR> @@ -79994,7 +83147,7 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file for which information is requested</P></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> @@ -80034,21 +83187,15 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </TD> </TR> <TR> -<TD>size</TD> -<TD>int64</TD> -<TD><P>Number of bytes in contents</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The current time at which this account is set to expire</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -80059,15 +83206,21 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -80075,22 +83228,18 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>True if deleted but not yet expired</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -80101,15 +83250,31 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -80120,7 +83285,7 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </thead> <tbody> <TR> -<TD>key</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -80138,15 +83303,15 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -80169,9 +83334,9 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -80180,33 +83345,15 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -80217,38 +83364,26 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference </TD> </TR> <tbody> @@ -80258,71 +83393,107 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> -<tbody> -</TABLE> -<div class="file-heading"> -<H2 id="FileService.proto">FileService.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileService"><span class="BigBadge">Service</span>FileService</H3> +<TR> +<TD> </TD> +<TD colspan=2> <P></P> <table class="field-table"> <thead> <TR> -<TD>RPC</TD> -<TD>Request</TD> -<TD>Response</TD> -<TD>Comments</TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>createFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>updateFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates a file by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>deleteFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>appendContent </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>getFileContent </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the file content by submitting the query. The grpc server returns the Response</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>getFileInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the file information by submitting the query. The grpc server returns the Response</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -<div class="file-heading"> -<H2 id="FileUpdate.proto">FileUpdate.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpdateTransactionBody</H3> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<TR> +<TD> </TD> +<TD colspan=2> <table class="field-table"> <thead> <TR> @@ -80333,15 +83504,15 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -80364,9 +83535,9 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -80375,15 +83546,33 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -80394,26 +83583,56 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keys</TD> +<TD>keyList</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -80438,7 +83657,31 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -80560,18 +83803,20 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -80582,8 +83827,6 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -80593,20 +83836,15 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="Freeze.proto">Freeze.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransactionBody</H3> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -80617,79 +83855,39 @@ <H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransa </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> -<div class="file-heading"> -<H2 id="FreezeService.proto">FreezeService.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="FreezeService"><span class="BigBadge">Service</span>FreezeService</H3> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>RPC</TD> -<TD>Request</TD> -<TD>Response</TD> -<TD>Comments</TD> +</TD> </TR> -</thead> <tbody> -<TR> -<TD>freeze </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> -</TR> - +</TABLE> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="GetByKey.proto">GetByKey.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> -<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>entity</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -80700,9 +83898,20 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for the cryptocurrency account</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> @@ -80739,18 +83948,23 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>The claim details attached to an account</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -80761,15 +83975,15 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -80792,9 +84006,9 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -80803,21 +84017,21 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -80828,15 +84042,32 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -80958,18 +84189,20 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -80980,8 +84213,6 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -80991,15 +84222,15 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -81010,11 +84241,17 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -81022,19 +84259,21 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -81045,32 +84284,27 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract ID that identifies instance</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -81109,32 +84343,34 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> -<H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> -<P> Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -81145,15 +84381,21 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -81164,33 +84406,37 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -81201,34 +84447,39 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -81241,13 +84492,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -81256,9 +84501,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -81303,15 +84548,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -81322,44 +84567,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -81370,56 +84586,43 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -81430,15 +84633,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -81461,9 +84664,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -81472,57 +84675,41 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> +</TABLE> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -81533,38 +84720,21 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -81575,33 +84745,20 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -81612,56 +84769,39 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -81672,34 +84812,32 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -81710,6 +84848,8 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -81719,15 +84859,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -81738,51 +84878,39 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -81793,104 +84921,104 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for which the records should be retrieved</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -81912,21 +85040,22 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="CryptoGetStakersResponse"><span class="BigBadge">Message</span>CryptoGetStakersResponse</H3> +<P> Response when the client sends the node CryptoGetStakersQuery </P> <table class="field-table"> <thead> <TR> @@ -81937,14 +85066,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -81955,1138 +85085,698 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> -</TD> +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> + <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> -</TD> +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>stakers</TD> +<TD><a href="#AllProxyStakers">AllProxyStakers</a></TD> +<TD><P>List of accounts proxy staking to this account, and the amount each is currently proxy staking</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> <table class="field-table"> <thead> <TR> @@ -83097,15 +85787,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that is being proxy staked to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -83128,110 +85818,26 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>proxyStaker</TD> +<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> +<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> information about a single account that is proxy staking </P> <table class="field-table"> <thead> <TR> @@ -83242,39 +85848,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The Account ID that is proxy staking</P></TD> </TR> <TR> @@ -83314,46 +85890,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>amount</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The number of hbars that are currently proxy staked</P></TD> </TR> <tbody> @@ -83361,16 +85900,16 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> +<P> information about a single account that is proxy staking </P> <table class="field-table"> <thead> <TR> @@ -83381,26 +85920,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that is proxy staking</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -83422,232 +85950,109 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>The number of hbars that are currently proxy staked</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> +<div class="file-heading"> +<H2 id="CryptoService.proto">CryptoService.proto</H2> +<a href="#title">Top</a> +</div> +<P> The request and responses for different crypto services. </P> +<H3 id="CryptoService"><span class="BigBadge">Service</span>CryptoService</H3> +<P></P> <table class="field-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RPC</TD> +<TD>Request</TD> +<TD>Response</TD> +<TD>Comments</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>createAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>updateAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates an account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>cryptoTransfer </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>cryptoDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>addClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>deleteClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>getClaim </TD><TD>Query</TD><TD>Response</TD>Retrieves the claim for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>getAccountRecords </TD><TD>Query</TD><TD>Response</TD>Retrieves the record(fetch by AccountID ID) for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>cryptoGetBalance </TD><TD>Query</TD><TD>Response</TD>Retrieves the balance for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>getAccountInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the account information for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>getTransactionReceipts </TD><TD>Query</TD><TD>Response</TD>Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee.<TD><P></P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>getFastTransactionRecord </TD><TD>Query</TD><TD>Response</TD>Retrieves the transaction record by TxID which last for 180sec only for no fee.<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>getTxRecordByTxID </TD><TD>Query</TD><TD>Response</TD>Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>getStakersByAccountID </TD><TD>Query</TD><TD>Response</TD>Retrieves the stakers for a node by account ID by submitting the query.<TD><P></P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<div class="file-heading"> +<H2 id="CryptoTransfer.proto">CryptoTransfer.proto</H2> +<a href="#title">Top</a> +</div> +<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<H3 id="AccountAmount"><span class="BigBadge">Message</span>AccountAmount</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -83658,9 +86063,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> @@ -83700,15 +86105,16 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<tbody> +</TABLE> + +<H3 id="CryptoTransferTransactionBody"><span class="BigBadge">Message</span>CryptoTransferTransactionBody</H3> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -83719,43 +86125,34 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -83766,9 +86163,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> @@ -83808,9 +86205,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -83818,34 +86215,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> -<TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> <tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> +<H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> <P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> @@ -83865,7 +86243,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -83931,23 +86309,13 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> +<div class="file-heading"> +<H2 id="CryptoUpdate.proto">CryptoUpdate.proto</H2> +<a href="#title">Top</a> +</div> <P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>CryptoUpdateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -84008,7 +86376,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -84326,7 +86694,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -84356,7 +86724,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -84418,18 +86786,13 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<div class="file-heading"> +<H2 id="Duration.proto">Duration.proto</H2> +<a href="#title">Top</a> +</div> +<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<H3 id="Duration"><span class="BigBadge">Message</span>Duration</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -84440,7 +86803,239 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>fileID</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ExchangeRate.proto">ExchangeRate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Values from these proto denotes habr and cents(USD) conversion </P> +<H3 id="ExchangeRate"><span class="BigBadge">Message</span>ExchangeRate</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H3> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="FileAppend.proto">FileAppend.proto</H2> +<a href="#title">Top</a> +</div> +<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppendTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> <TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> @@ -84490,18 +87085,13 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<div class="file-heading"> +<H2 id="FileCreate.proto">FileCreate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.<BR>The file contains the given contents (possibly empty). The file will automatically disappear at the fileExpirationTime, unless its expiration is extended by another transaction before that time. If the file is deleted, then its contents will become empty and it will be marked as deleted until it expires, and then it will cease to exist. See FileGetInfoQuery for more information about files.<BR>The keys field is a list of keys. All the keys on the list must sign to create or modify a file, but only one of them needs to sign in order to delete the file. Each of those "keys" may itself be threshold key containing other keys (including other threshold keys). In other words, the behavior is an AND for create/modify, OR for delete. This is useful for acting as a revocation server. If it is desired to have the behavior be AND for all 3 operations (or OR for all 3), then the list should have only a single Key, which is a threshold key, with N=1 for OR, N=M for AND.<BR>If a file is created without ANY keys in the keys field, the file is immutable ONLY the expirationTime of the file can be changed using FileUpdate API. The file contents or its keys cannot be changed.<BR>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.<BR>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.</P> +<H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCreateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -84520,7 +87110,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -84575,7 +87165,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -84744,7 +87334,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -84810,7 +87400,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -85010,18 +87600,13 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> +<div class="file-heading"> +<H2 id="FileDelete.proto">FileDelete.proto</H2> +<a href="#title">Top</a> +</div> <P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -85076,18 +87661,13 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<div class="file-heading"> +<H2 id="FileGetContents.proto">FileGetContents.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the contents of a file. The content field is empty (no bytes) if the file is empty. </P> +<H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetContentsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -85098,15 +87678,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -85117,38 +87697,33 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -85159,32 +87734,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -85195,15 +87753,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -85214,14 +87772,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -85232,15 +87791,32 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -85263,9 +87839,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -85273,34 +87849,21 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -85311,73 +87874,85 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> + <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> <table class="field-table"> <thead> <TR> @@ -85388,14 +87963,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -85406,15 +87982,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -85437,9 +88013,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -85448,40 +88024,21 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>gas</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD>amount</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> @@ -85489,18 +88046,35 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -85511,31 +88085,38 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -85546,7 +88127,7 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -85564,15 +88145,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -85595,9 +88176,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -85606,15 +88187,33 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -85625,45 +88224,62 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -85674,81 +88290,51 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +</TD> </TR> - <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -85771,9 +88357,9 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -85782,41 +88368,81 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>bodyBytes</TD> +<TD>constructorParameters</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -85827,21 +88453,32 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -85852,20 +88489,33 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -85876,39 +88526,56 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -85919,32 +88586,34 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -85955,8 +88624,6 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -85966,15 +88633,15 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -85985,39 +88652,50 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -86028,104 +88706,93 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The key to search for. It must not contain a contractID nor a ThresholdSignature.</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -86322,11 +88989,16 @@ <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> -<H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse</H3> -<P> Response when the client sends the node GetByKeyQuery </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -86337,15 +89009,38 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -86356,621 +89051,183 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a file </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> -</TR> - -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> -</TR> - -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> -</TR> - -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> -</TR> - -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - -<TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - -<TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - -<TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> - -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> - -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> -</TR> - -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - -<TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - -<TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> - -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - -<TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> - -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> - -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> - -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> - -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - -<TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - -<TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -86979,41 +89236,40 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -87021,70 +89277,23 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - <tbody> </TABLE> - -</TD> -</TR> -<TR> -<TD>entities</TD> -<TD><a href="#EntityID">EntityID</a> (repeated)</TD> -<TD><P>The list of entities that include this public key in their associated Key list</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>entity</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for the cryptocurrency account</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -87095,38 +89304,15 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>claim</TD> <TD><a href="#Claim">Claim</a></TD> -<TD><P>The claim details attached to an account</P></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -87212,7 +89398,7 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -87375,7 +89561,7 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -87399,18 +89585,23 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -87421,32 +89612,46 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract ID that identifies instance</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -87485,78 +89690,34 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="GetBySolidityID.proto">GetBySolidityID.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidityIDQuery</H3> -<P> Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -87567,34 +89728,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -87605,51 +89753,37 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -87660,23 +89794,17 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -87684,13 +89812,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -87730,21 +89866,33 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>transactionFee</TD> +<TD>sendRecordThreshold</TD> <TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -87766,64 +89914,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -87836,42 +89935,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -87880,34 +89944,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -87929,27 +89974,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -88144,24 +90183,36 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -88201,15 +90252,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -88220,45 +90271,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -88266,70 +90293,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -88340,15 +90318,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -88371,9 +90349,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -88382,33 +90360,26 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -88419,21 +90390,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -88444,37 +90409,34 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -88485,50 +90447,59 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -88539,15 +90510,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -88570,45 +90541,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -88617,15 +90552,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -88865,15 +90800,20 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -88884,26 +90824,28 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -88914,49 +90856,29 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -88967,15 +90889,26 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -88986,21 +90919,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -89009,7 +90936,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -89027,15 +90954,34 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89046,38 +90992,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -89100,9 +91023,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -89110,42 +91033,27 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89156,15 +91064,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89175,21 +91083,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -89197,16 +91099,10 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -89231,7 +91127,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -89386,15 +91282,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89405,36 +91307,26 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -89445,15 +91337,32 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -89648,24 +91557,42 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -89688,9 +91615,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -89698,34 +91625,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89736,26 +91650,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -89768,7 +91671,19 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -89777,15 +91692,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89796,15 +91711,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -89813,15 +91728,34 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -89943,20 +91877,18 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -89967,6 +91899,8 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -89976,15 +91910,26 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -89995,44 +91940,14 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> <table class="field-table"> <thead> <TR> @@ -90043,15 +91958,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -90074,9 +91989,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -90085,15 +92000,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -90116,9 +92031,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -90128,38 +92043,16 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -90170,21 +92063,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -90192,27 +92073,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90223,15 +92098,14 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -90242,15 +92116,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -90261,15 +92135,38 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -90292,20 +92189,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -90315,24 +92201,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90343,15 +92226,44 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90362,38 +92274,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -90591,15 +92486,52 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -90622,9 +92554,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -90633,20 +92565,33 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -90657,28 +92602,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -90689,29 +92627,37 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -90722,26 +92668,39 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90754,13 +92713,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -90769,14 +92722,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -90787,34 +92741,43 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90825,15 +92788,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -90856,20 +92819,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -90878,34 +92830,21 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -90933,34 +92872,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -91082,18 +93002,20 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -91104,8 +93026,6 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -91115,21 +93035,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -91140,62 +93054,39 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -91392,148 +93283,16 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -91546,285 +93305,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -91833,15 +93314,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -91864,41 +93345,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -91912,33 +93361,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -91949,57 +93380,15 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -92022,9 +93411,9 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -92032,79 +93421,11 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - <TR> <TD>consensusSubmitMessage</TD> <TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> @@ -92201,7 +93522,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -92226,7 +93547,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -92293,7 +93614,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -92359,7 +93680,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -92378,7 +93699,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -92462,7 +93783,7 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -92502,16 +93823,52 @@ <H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidity </TD> </TR> <TR> -<TD>solidityID</TD> -<TD>string</TD> -<TD><P>The ID in the format used by Solidity</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file whose contents are requested</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> -<H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolidityIDResponse</H3> -<P> Response when the client sends the node GetBySolidityIDQuery </P> +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetContentsResponse</H3> +<P> Response when the client sends the node FileGetContentsQuery </P> <table class="field-table"> <thead> <TR> @@ -92530,7 +93887,7 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93150,12 +94507,12 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -93172,7 +94529,7 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -93224,15 +94581,15 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for the cryptocurrency account</P></TD> +<TD>fileContents</TD> +<TD><a href="#FileGetContentsResponse.FileContents">FileGetContentsResponse.FileContents</a></TD> +<TD><P>the file ID and contents (a state proof can be generated for this)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93243,32 +94600,9 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file Id for the file</P></TD> +<TD><P>The file ID of the file whose contents are being returned</P></TD> </TR> <TR> @@ -93308,15 +94642,40 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>A smart contract ID for the instance (if this is included, then the associated accountID will also be included)</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes contained in the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</span>FileGetContentsResponse.FileContents</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file whose contents are being returned</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -93339,9 +94698,9 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -93349,52 +94708,22 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes contained in the file</P></TD> +</TR> + <tbody> </TABLE> <div class="file-heading"> -<H2 id="Query.proto">Query.proto</H2> +<H2 id="FileGetInfo.proto">FileGetInfo.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Query"><span class="BigBadge">Message</span>Query</H3> -<P> A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>query</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>getByKey</TD> -<TD><a href="#GetByKeyQuery">GetByKeyQuery</a></TD> -<TD><P>Get all entities associated with a given key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. </P> +<P> Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. </P> +<H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -93432,7 +94761,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93469,7 +94798,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93507,7 +94836,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93638,7 +94967,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93698,7 +95027,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93782,7 +95111,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -93843,7 +95172,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -94103,7 +95432,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -94139,7 +95468,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -94205,7 +95534,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -94422,7 +95751,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -94483,7 +95812,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -94519,7 +95848,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -94767,7 +96096,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -94850,7 +96179,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95020,7 +96349,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -95039,7 +96368,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95125,7 +96454,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -95288,7 +96617,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95328,7 +96657,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95347,7 +96676,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -95619,7 +96948,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95649,7 +96978,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -95715,7 +97044,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -95926,7 +97255,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96034,7 +97363,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96144,7 +97473,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96226,7 +97555,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96287,7 +97616,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -96605,7 +97934,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96635,7 +97964,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96708,7 +98037,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96780,7 +98109,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96799,7 +98128,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -96854,7 +98183,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -97023,7 +98352,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97089,7 +98418,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -97300,7 +98629,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97366,7 +98695,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97427,7 +98756,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97482,7 +98811,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -97656,7 +98985,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97814,7 +99143,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97942,7 +99271,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -97988,27 +99317,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -98019,15 +99579,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -98050,9 +99610,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -98061,41 +99621,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -98106,21 +99658,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -98131,63 +99683,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -98198,15 +99724,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -98218,42 +99738,55 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -98264,15 +99797,43 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -98283,20 +99844,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -98307,104 +99863,80 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The key to search for. It must not contain a contractID nor a ThresholdSignature.</P></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -98599,23 +100131,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>getBySolidityID</TD> -<TD><a href="#GetBySolidityIDQuery">GetBySolidityIDQuery</a></TD> -<TD><P>Get the IDs in the format used in transactions, given the format used in Solidity</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -98626,15 +100153,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -98645,15 +100171,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -98664,52 +100190,56 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -98720,15 +100250,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -98739,32 +100275,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -98775,23 +100316,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -98799,19 +100334,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -98822,21 +100359,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -98845,21 +100370,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -98870,56 +100389,43 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -98930,15 +100436,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -98961,9 +100467,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -98971,39 +100477,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -99014,15 +100502,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -99045,9 +100533,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -99056,15 +100544,41 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -99075,14 +100589,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -99093,15 +100614,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -99112,56 +100638,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -99172,34 +100681,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -99210,6 +100717,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -99219,15 +100728,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -99238,51 +100747,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -99293,104 +100790,104 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -99412,21 +100909,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> +<H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoResponse</H3> +<P> Response when the client sends the node FileGetInfoQuery </P> <table class="field-table"> <thead> <TR> @@ -99437,14 +100935,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -99455,727 +100954,621 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> -</TD> +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> + <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> -</TD> +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> + <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> -</TD> +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> + <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> -</TD> +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> + <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> -</TD> +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> + <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> -</TD> +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> -</TD> +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> + <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> -</TD> +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> + <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -100184,40 +101577,41 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -100225,23 +101619,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>fileInfo</TD> +<TD><a href="#FileGetInfoResponse.FileInfo">FileGetInfoResponse.FileInfo</a></TD> +<TD><P>The information about the file (a state proof can be generated for this)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -100252,15 +101656,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -100271,15 +101675,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>size</TD> +<TD>int64</TD> +<TD><P>Number of bytes in contents</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The current time at which this account is set to expire</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -100290,21 +101723,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -100313,15 +101740,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>True if deleted but not yet expired</P></TD> </TR> <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> </TR> <TR> @@ -100346,7 +101773,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -100500,16 +101927,35 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileGetInfoResponse.FileInfo</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -100520,9 +101966,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -100530,26 +101988,64 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>size</TD> +<TD>int64</TD> +<TD><P>Number of bytes in contents</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The current time at which this account is set to expire</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>True if deleted but not yet expired</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -100560,15 +102056,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -100687,25 +102183,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>List of all the keys that can sign</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -100715,11 +102192,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> @@ -100728,25 +102200,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>A list of Keys of the Key type.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -100755,92 +102208,78 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> -<TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<div class="file-heading"> +<H2 id="FileService.proto">FileService.proto</H2> +<a href="#title">Top</a> +</div> +<P> The request and responses for different file services. </P> +<H3 id="FileService"><span class="BigBadge">Service</span>FileService</H3> +<P></P> <table class="field-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RPC</TD> +<TD>Request</TD> +<TD>Response</TD> +<TD>Comments</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>createFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>updateFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates a file by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>deleteFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>appendContent </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>getFileContent </TD><TD>Query</TD><TD>Response</TD>Retrieves the file content by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>getFileInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the file information by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="FileUpdate.proto">FileUpdate.proto</H2> +<a href="#title">Top</a> +</div> +<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.<BR>If a file was created without ANY keys in the keys field, ONLY the expirationTime of the file can be changed using this call. The file contents or its keys cannot be changed.</P> +<H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpdateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -100851,26 +102290,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -100883,7 +102311,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -100892,15 +102332,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -100911,15 +102351,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -100928,15 +102368,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -101058,20 +102517,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -101082,6 +102539,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -101091,15 +102550,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="Freeze.proto">Freeze.proto</H2> +<a href="#title">Top</a> +</div> +<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -101110,44 +102575,63 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> + <tbody> </TABLE> -</TD> +<div class="file-heading"> +<H2 id="FreezeService.proto">FreezeService.proto</H2> +<a href="#title">Top</a> +</div> +<P> The request and responses for freeze service. </P> +<H3 id="FreezeService"><span class="BigBadge">Service</span>FreezeService</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>RPC</TD> +<TD>Request</TD> +<TD>Response</TD> +<TD>Comments</TD> </TR> +</thead> +<tbody> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>freeze </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="GetByKey.proto">GetByKey.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. </P> +<H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> +<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> <table class="field-table"> <thead> <TR> @@ -101158,15 +102642,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>entity</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -101177,32 +102660,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD><P>The Account ID for the cryptocurrency account</P></TD> </TR> <TR> @@ -101239,23 +102699,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>The claim details attached to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -101266,9 +102721,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -101308,26 +102763,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>hashToDelete</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -101338,15 +102788,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -101357,15 +102807,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -101376,15 +102825,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -101407,9 +102856,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -101418,36 +102867,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -101458,57 +102904,62 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -101519,14 +102970,31 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -101537,9 +103005,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>The smart contract ID that identifies instance</P></TD> </TR> <TR> @@ -101578,34 +103069,51 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -101616,21 +103124,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -101641,37 +103142,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -101682,33 +103180,45 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -101747,21 +103257,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -101772,61 +103282,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> +</TABLE> +</TD> +</TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> +<TD>transactionValidDuration</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -101848,43 +103341,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>data</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -101902,34 +103371,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -101940,15 +103390,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -101971,9 +103421,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -101982,9 +103432,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> @@ -101993,15 +103455,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -102012,15 +103474,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -102031,15 +103493,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -102048,34 +103516,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -102194,6 +103643,25 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -102203,6 +103671,11 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -102211,6 +103684,25 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -102219,32 +103711,116 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> +<TD>constructorParameters</TD> <TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -102268,7 +103844,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -102304,13 +103880,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -102507,87 +104083,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -102598,15 +104114,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -102629,9 +104145,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -102642,13 +104158,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -102676,34 +104192,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -102825,31 +104322,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -102857,27 +104349,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -102888,33 +104374,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -102937,9 +104429,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -102948,15 +104440,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -102967,21 +104459,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -102989,18 +104469,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -103011,9 +104489,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -103021,21 +104511,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -103046,7 +104542,49 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -103064,15 +104602,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -103095,9 +104633,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -103106,9 +104644,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -103155,15 +104693,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -103174,56 +104712,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> @@ -103240,15 +104731,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -103271,52 +104762,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>bodyBytes</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -103327,21 +104798,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -103352,13 +104817,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -103376,39 +104835,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> -</TR> - -<TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -103419,81 +104854,56 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -103504,60 +104914,42 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> +</TABLE> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +</TD> </TR> - <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - -<tbody> -</TABLE> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> @@ -103569,41 +104961,28 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -103616,27 +104995,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>solidityID</TD> -<TD>string</TD> -<TD><P>The ID in the format used by Solidity</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCallLocal</TD> -<TD><a href="#ContractCallLocalQuery">ContractCallLocalQuery</a></TD> -<TD><P>Call a function of a smart contract instance</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -103647,15 +105020,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered.</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -103666,15 +105039,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -103685,14 +105057,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -103703,34 +105076,56 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -103741,15 +105136,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -103760,32 +105161,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -103796,23 +105202,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -103820,13 +105220,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -103866,21 +105274,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> +<TD>sendRecordThreshold</TD> <TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -103902,64 +105322,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -103972,42 +105343,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -104016,34 +105352,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -104065,27 +105382,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -104280,24 +105591,78 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>gas</TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>initialBalance</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> @@ -104334,18 +105699,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -104356,9 +105726,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -104367,21 +105768,83 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>constructorParameters</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -104394,7 +105857,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -104403,15 +105878,55 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -104433,21 +105948,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -104645,26 +106166,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -104675,40 +106185,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -104717,62 +106208,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> +<TD>proxyFraction</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>sendRecordThresholdField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -104790,184 +106232,28 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -104978,38 +106264,29 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105031,15 +106308,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105050,32 +106327,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -105084,34 +106344,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -105122,37 +106362,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -105163,15 +106400,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -105194,9 +106431,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -105205,40 +106442,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> <tbody> @@ -105246,42 +106452,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105292,15 +106472,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105311,21 +106491,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -105333,16 +106507,10 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -105367,7 +106535,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -105522,15 +106690,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105541,36 +106715,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -105581,15 +106745,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -105784,24 +106965,42 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -105824,9 +107023,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -105834,34 +107033,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105872,26 +107058,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -105904,7 +107079,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -105913,15 +107100,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -105932,15 +107119,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -105949,15 +107136,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -106079,20 +107285,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -106103,6 +107307,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -106112,15 +107318,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -106131,44 +107348,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> <table class="field-table"> <thead> <TR> @@ -106179,15 +107366,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -106210,9 +107397,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -106221,15 +107408,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -106252,9 +107439,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -106264,38 +107451,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -106306,21 +107471,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -106328,27 +107481,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -106359,15 +107506,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -106378,15 +107524,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -106397,15 +107543,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -106428,20 +107597,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -106451,24 +107609,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -106479,15 +107634,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -106498,38 +107682,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -106727,15 +107894,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -106746,43 +107913,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -106793,61 +107950,56 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -106858,26 +108010,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -106888,31 +108035,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -106923,17 +108076,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> <tbody> @@ -106942,15 +108100,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -106961,15 +108119,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -106992,9 +108161,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -107002,27 +108171,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -107033,15 +108196,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -107052,15 +108215,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -107069,15 +108238,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -107088,15 +108263,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -107218,18 +108410,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -107240,8 +108434,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -107251,21 +108443,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -107276,62 +108462,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -107526,150 +108689,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -107682,285 +108713,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -107969,15 +108722,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -108000,41 +108753,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -108048,33 +108769,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -108085,57 +108788,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -108158,9 +108819,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -108168,79 +108829,11 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - <TR> <TD>consensusSubmitMessage</TD> <TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> @@ -108337,7 +108930,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -108362,7 +108955,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -108429,7 +109022,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -108495,7 +109088,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -108514,7 +109107,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -108598,7 +109191,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -108638,9 +109231,46 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The key to search for. It must not contain a contractID nor a ThresholdSignature.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -108680,38 +109310,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the amount of gas to use for the call. All of the gas offered will be charged for.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>maxResultSize</TD> -<TD>int64</TD> -<TD><P>max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractGetInfo</TD> -<TD><a href="#ContractGetInfoQuery">ContractGetInfoQuery</a></TD> -<TD><P>Get information about a smart contract instance</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -108722,15 +109347,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -108741,33 +109372,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -108778,15 +109413,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse</H3> +<P> Response when the client sends the node GetByKeyQuery </P> <table class="field-table"> <thead> <TR> @@ -108797,15 +109451,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -108816,775 +109470,664 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> -</TD> +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> + <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> <TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> + <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> + <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> -</TD> +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> + <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> + <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> -</TD> +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> + <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> -</TD> +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> + <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> -</TD> +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> + <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> -</TD> +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> + <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>INVALID_SUBMIT_KEY</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> -</thead> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -109593,33 +110136,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> </TR> <TR> -<TD>RSA_3072</TD> +<TD>stateProof</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> </TR> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>entities</TD> +<TD><a href="#EntityID">EntityID</a> (repeated)</TD> +<TD><P>The list of entities that include this public key in their associated Key list</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> <table class="field-table"> <thead> <TR> @@ -109630,21 +110172,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>entity</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -109655,37 +110190,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for the cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -109696,33 +110209,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -109731,15 +110232,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>The claim details attached to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -109750,15 +110251,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -109781,9 +110282,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -109792,15 +110293,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -109811,32 +110318,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -109958,20 +110448,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -109982,6 +110470,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -109991,15 +110481,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -110010,17 +110500,11 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -110028,21 +110512,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -110065,9 +110547,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -110076,15 +110558,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The smart contract ID that identifies instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -110095,9 +110577,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -110105,16 +110599,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> +<div class="file-heading"> +<H2 id="GetBySolidityID.proto">GetBySolidityID.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. </P> +<H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidityIDQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -110125,49 +110626,52 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> <table class="field-table"> <thead> <TR> @@ -110178,15 +110682,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -110197,37 +110701,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -110238,9 +110739,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -110277,18 +110795,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -110311,9 +110834,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -110321,23 +110844,63 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> <table class="field-table"> <thead> <TR> @@ -110348,15 +110911,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -110367,15 +110930,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -110398,9 +110961,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -110409,58 +110972,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -110471,15 +111014,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -110502,169 +111045,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -110861,16 +111261,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + <TR> <TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -110909,34 +111315,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -110957,16 +111345,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -110990,7 +111384,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -111026,13 +111420,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -111227,186 +111621,12 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -111415,53 +111635,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -111472,15 +111654,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -111503,66 +111685,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -111573,21 +111715,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -111596,15 +111732,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -111844,20 +111980,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -111868,28 +111999,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -111900,29 +112029,49 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -111933,26 +112082,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -111963,15 +112101,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -111980,7 +112124,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -111998,34 +112142,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -112036,15 +112161,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -112067,9 +112215,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -112077,27 +112225,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -112108,15 +112252,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -112127,15 +112271,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -112143,10 +112312,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -112171,7 +112346,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -112326,21 +112501,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -112351,26 +112520,36 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -112381,32 +112560,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -112601,42 +112763,24 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -112659,50 +112803,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -112713,21 +112851,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -112736,15 +112862,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -112755,15 +112881,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -112772,15 +112892,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -112791,15 +112911,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -112921,31 +113058,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -112953,27 +113085,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -112984,14 +113110,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -113002,15 +113158,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -113033,9 +113189,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -113044,15 +113200,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -113075,9 +113231,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -113087,16 +113243,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -113107,9 +113266,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -113117,21 +113307,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -113142,14 +113338,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -113160,15 +113357,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -113179,38 +113376,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -113233,9 +113407,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -113245,21 +113430,24 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -113270,27 +113458,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -113299,33 +113500,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -113336,15 +113537,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -113367,9 +113568,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -113378,90 +113579,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -113472,39 +113616,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -113515,32 +113641,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -113551,8 +113654,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -113562,34 +113663,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -113600,63 +113682,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - +Self Reference </TD> </TR> <tbody> @@ -113664,64 +113698,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> -<thead> -<TR> -<TD>Enum Name</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> - <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract for which information is requested</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -113744,50 +113737,31 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>contractGetBytecode</TD> -<TD><a href="#ContractGetBytecodeQuery">ContractGetBytecodeQuery</a></TD> -<TD><P>Get bytecode used by a smart contract instance</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Get the bytecode for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -113798,26 +113772,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> -</thead> + <tbody> +</TABLE> <TR> -<TD>bodyData</TD> +<TD>receiveRecordThresholdField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -113835,53 +113804,29 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> +</TABLE> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -113894,13 +113839,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -113909,15 +113848,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -113928,43 +113867,31 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -113975,104 +113902,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114083,15 +113940,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -114114,9 +113971,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -114125,21 +113982,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> <tbody> @@ -114148,15 +113993,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114167,15 +114012,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114186,21 +114031,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -114209,15 +114048,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -114336,25 +114194,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>List of all the keys that can sign</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -114364,11 +114203,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> @@ -114377,25 +114211,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>A list of Keys of the Key type.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -114404,116 +114219,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>constructorParameters</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114537,7 +114268,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -114573,13 +114304,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -114774,29 +114505,89 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114807,15 +114598,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -114838,9 +114629,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -114851,13 +114642,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -114885,15 +114676,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -115015,20 +114825,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -115039,6 +114847,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -115048,15 +114858,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -115067,39 +114888,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -115122,9 +114937,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -115133,15 +114948,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -115152,9 +114967,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -115162,16 +114989,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -115182,21 +115011,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -115204,27 +115021,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -115235,15 +115046,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -115254,56 +115064,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -115326,9 +115095,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -115337,9 +115106,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transferContractID</TD> +<TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -115386,34 +115155,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -115424,40 +115174,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -115466,21 +115203,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -115491,15 +115222,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -115621,18 +115358,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -115643,8 +115382,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -115654,15 +115391,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -115673,14 +115410,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> -<tbody> -</TABLE> - +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -115690,38 +115428,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -115918,82 +115639,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -116015,15 +115670,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -116036,24 +115691,60 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -116075,21 +115766,69 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -116284,23 +116023,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -116311,15 +116045,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -116330,38 +116063,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -116384,9 +116094,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -116394,21 +116104,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> + <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -116419,15 +116142,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -116438,49 +116167,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -116491,34 +116208,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -116529,9 +116251,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -116568,22 +116301,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -116592,15 +116309,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -116611,15 +116328,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -116642,9 +116359,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -116652,34 +116369,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -116690,15 +116394,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -116721,9 +116425,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -116732,33 +116436,41 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>message</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ECDSA_384</TD> +<TD>bodyBytes</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -116769,21 +116481,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -116794,37 +116506,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -116835,39 +116530,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> + <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -116878,75 +116573,62 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TD> </TR> - <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -116957,29 +116639,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -116990,26 +116658,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -117020,113 +116682,82 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -117134,27 +116765,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>solidityID</TD> +<TD>string</TD> +<TD><P>The ID in the format used by Solidity</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<tbody> +</TABLE> + +<H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolidityIDResponse</H3> +<P> Response when the client sends the node GetBySolidityIDQuery </P> <table class="field-table"> <thead> <TR> @@ -117165,15 +116791,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -117184,1170 +116810,664 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>id</TD> -<TD>oneof</TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> @@ -118356,52 +117476,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> </TR> -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for the cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -118424,52 +117524,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file Id for the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -118480,88 +117554,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>A smart contract ID for the instance (if this is included, then the associated accountID will also be included)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -118572,42 +117596,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> @@ -118616,37 +117621,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<div class="file-heading"> +<H2 id="Query.proto">Query.proto</H2> +<a href="#title">Top</a> +</div> +<P> A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. </P> +<H3 id="Query"><span class="BigBadge">Message</span>Query</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -118657,13 +117638,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> +<TD>query</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -118681,151 +117656,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> -<thead> -<TR> -<TD>Enum Name</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract for which information is requested</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ContractGetRecords</TD> -<TD><a href="#ContractGetRecordsQuery">ContractGetRecordsQuery</a></TD> -<TD><P>Get Records of the contract instance</P></TD> +<TD>getByKey</TD> +<TD><a href="#GetByKeyQuery">GetByKeyQuery</a></TD> +<TD><P>Get all entities associated with a given key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -118863,7 +117702,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -118900,7 +117739,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -118938,7 +117777,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119069,7 +117908,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119129,7 +117968,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119213,7 +118052,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119274,7 +118113,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -119534,7 +118373,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119570,7 +118409,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119636,7 +118475,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -119853,7 +118692,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119914,7 +118753,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -119950,7 +118789,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -120198,7 +119037,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -120281,7 +119120,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -120451,7 +119290,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -120470,7 +119309,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -120556,7 +119395,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -120719,7 +119558,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -120759,7 +119598,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -120778,7 +119617,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -121050,7 +119889,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121080,7 +119919,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121146,7 +119985,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -121357,7 +120196,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121465,7 +120304,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121575,7 +120414,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121657,7 +120496,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -121718,7 +120557,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -122036,7 +120875,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122066,7 +120905,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122139,7 +120978,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122211,7 +121050,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122230,7 +121069,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122285,7 +121124,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -122454,7 +121293,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122520,7 +121359,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -122731,7 +121570,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122797,7 +121636,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122858,7 +121697,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -122913,7 +121752,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -123087,7 +121926,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -123245,7 +122084,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -123373,7 +122212,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -123419,27 +122258,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -123450,15 +122520,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -123481,9 +122551,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -123492,90 +122562,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -123586,39 +122599,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -123629,32 +122624,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -123665,8 +122637,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -123676,34 +122646,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -123714,55 +122665,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +Self Reference +</TD> </TR> - -<tbody> -</TABLE> <tbody> </TABLE> @@ -123770,72 +122683,51 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract instance for which the records should be retrieved</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -123858,9 +122750,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -123874,15 +122766,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptogetAccountBalance</TD> -<TD><a href="#CryptoGetAccountBalanceQuery">CryptoGetAccountBalanceQuery</a></TD> -<TD><P>Get the current balance in a cryptocurrency account</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -123893,15 +122785,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -123912,90 +122804,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> +<TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -124023,15 +122869,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -124042,43 +122888,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -124101,9 +122937,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -124112,62 +122948,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -124178,34 +122985,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -124216,61 +123010,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -124281,57 +123051,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -124529,21 +123281,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>initialBalance</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>proxyAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -124582,52 +123352,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -124638,26 +123377,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -124679,39 +123407,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -124722,15 +123443,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -124753,9 +123474,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -124764,33 +123485,41 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>message</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ECDSA_384</TD> +<TD>bodyBytes</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -124801,21 +123530,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -124826,37 +123555,63 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> -</TD> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> + <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> +</TR> + +<TR> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -124867,9 +123622,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> @@ -124881,6 +123642,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<TR> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -124890,27 +123663,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -124921,15 +123688,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -124940,74 +123707,128 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>The key to search for. It must not contain a contractID nor a ThresholdSignature.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -125202,18 +124023,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>getBySolidityID</TD> +<TD><a href="#GetBySolidityIDQuery">GetBySolidityIDQuery</a></TD> +<TD><P>Get the IDs in the format used in transactions, given the format used in Solidity</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125224,38 +124050,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125266,26 +124088,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125296,49 +124125,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -125349,15 +124144,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125368,21 +124163,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -125391,27 +124180,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -125448,18 +124219,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -125482,9 +124258,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -125492,61 +124268,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125557,21 +124294,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -125580,40 +124305,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -125624,14 +124335,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -125644,7 +124356,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -125684,33 +124396,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -125721,62 +124438,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -125787,55 +124457,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -126032,16 +124685,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + <TR> <TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -126080,34 +124739,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -126128,16 +124769,22 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -126161,7 +124808,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -126197,13 +124844,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -126398,186 +125045,12 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -126586,53 +125059,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -126643,15 +125078,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -126674,66 +125109,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -126744,21 +125139,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -126767,15 +125156,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -127015,20 +125404,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -127039,28 +125423,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -127071,29 +125453,49 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127104,26 +125506,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -127134,15 +125525,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -127151,7 +125548,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -127169,34 +125566,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -127207,15 +125585,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -127238,9 +125639,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -127248,27 +125649,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -127279,15 +125676,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127298,15 +125695,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -127314,10 +125736,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -127342,7 +125770,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -127497,21 +125925,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127522,26 +125944,36 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127552,32 +125984,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -127772,42 +126187,24 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -127830,50 +126227,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> -<table class="field-table"> -<thead> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127884,21 +126275,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -127907,15 +126286,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -127926,15 +126305,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -127943,15 +126316,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -127962,15 +126335,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -128092,31 +126482,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -128124,27 +126509,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -128155,14 +126534,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -128173,15 +126582,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -128204,9 +126613,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -128215,15 +126624,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -128246,9 +126655,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -128258,16 +126667,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -128278,9 +126690,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -128288,21 +126731,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -128313,14 +126762,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -128331,15 +126781,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -128350,38 +126800,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -128404,9 +126831,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -128416,21 +126854,24 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -128441,27 +126882,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -128470,33 +126924,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -128507,15 +126961,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -128538,9 +126992,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -128549,41 +127003,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -128594,21 +127040,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -128619,63 +127065,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -128686,15 +127106,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -128708,40 +127122,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -128752,32 +127149,36 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>signature</TD> +<TD>sendRecordThresholdField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -128795,103 +127196,61 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>balanceSource</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -128902,15 +127261,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -128921,21 +127291,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -128944,15 +127308,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -128963,28 +127326,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <tbody> </TABLE> <tbody> @@ -128993,15 +127345,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoGetAccountRecords</TD> -<TD><a href="#CryptoGetAccountRecordsQuery">CryptoGetAccountRecordsQuery</a></TD> -<TD><P>Get all the records that currently exist for transactions involving an account</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129012,15 +127364,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -129031,71 +127383,49 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -</thead> + <tbody> -<TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> -</TR> +</TABLE> +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129106,15 +127436,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> +<TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129142,15 +127472,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -129161,43 +127491,52 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -129220,9 +127559,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -129231,62 +127570,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> -</TR> - -<TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -129297,99 +127607,68 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TD> </TR> - <TR> -<TD>functionParameters</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129400,15 +127679,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -129430,27 +127720,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -129645,30 +127929,42 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -129691,26 +127987,31 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129721,32 +128022,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -129759,7 +128043,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -129768,15 +128064,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129787,15 +128083,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -129804,15 +128100,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -129934,20 +128249,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -129958,6 +128271,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -129967,15 +128282,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -129986,50 +128312,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> +<table class="field-table"> +<thead> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -130040,9 +128349,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> @@ -130081,16 +128413,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<tbody> +</TABLE> <TR> <TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -130106,27 +128440,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -130137,7 +128470,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -130155,15 +128488,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -130186,9 +128519,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -130197,33 +128530,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -130234,42 +128549,23 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> <tbody> </TABLE> @@ -130277,19 +128573,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> +</TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -130300,64 +128598,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -130366,15 +128627,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -130385,26 +128646,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -130415,49 +128671,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> <table class="field-table"> <thead> <TR> @@ -130470,7 +128691,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -130510,33 +128731,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -130547,38 +128768,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -130589,23 +128793,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -130613,21 +128811,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -130638,101 +128834,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> -</TR> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -130854,18 +128988,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -130876,8 +129012,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -130887,15 +129021,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -130906,14 +129040,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> -<tbody> -</TABLE> - +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -130923,19 +129058,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -130946,15 +129083,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -130965,14 +129113,43 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -130983,15 +129160,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -131014,9 +129191,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -131025,58 +129202,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -131087,37 +129227,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -131128,45 +129263,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> +<table class="field-table"> +<thead> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -131189,9 +129312,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -131200,33 +129323,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -131237,26 +129360,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -131267,26 +129385,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -131297,32 +129426,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -131519,40 +129655,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -131563,21 +129675,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -131586,9 +129686,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>deleteAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -131633,15 +129733,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -131652,15 +129752,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -131683,9 +129783,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -131693,65 +129793,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -131762,15 +129818,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -131793,9 +129849,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -131804,9 +129860,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> <tbody> @@ -131816,43 +129872,29 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> +</TABLE> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -131863,38 +129905,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -131905,33 +129930,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -131942,56 +129954,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -132002,34 +129997,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -132040,6 +130033,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -132049,15 +130044,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -132068,39 +130063,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -132111,75 +130106,115 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>solidityID</TD> +<TD>string</TD> +<TD><P>The ID in the format used by Solidity</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallLocal</TD> +<TD><a href="#ContractCallLocalQuery">ContractCallLocalQuery</a></TD> +<TD><P>Call a function of a smart contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.<BR>This is performed locally on the particular node that the client is communicating with. It cannot change the state of the contract instance (and so, cannot spend anything from the instance's cryptocurrency account). It will not have a consensus timestamp. It cannot generate a record or a receipt. The response will contain the output returned by the function call. This is useful for calling getter functions, which purely read the state and don't change it. It is faster and cheaper than a normal call, because it is purely local to a single node.</P> <table class="field-table"> <thead> <TR> @@ -132190,29 +130225,52 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered.</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -132223,26 +130281,53 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>expirationTime</TD> +<TD>transactionValidStart</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -132270,14 +130355,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -132288,34 +130374,43 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -132326,15 +130421,123 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -132357,9 +130560,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -132368,9 +130571,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> @@ -132379,15 +130594,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -132398,15 +130613,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -132417,15 +130632,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -132434,34 +130655,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -132580,6 +130782,25 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -132589,6 +130810,11 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -132597,10 +130823,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> Self Reference +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <tbody> @@ -132610,27 +130860,106 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> <TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -132654,7 +130983,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -132690,13 +131019,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -132893,87 +131222,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -132984,15 +131253,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -133015,9 +131284,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -133028,13 +131297,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -133062,34 +131331,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -133211,31 +131461,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -133243,27 +131488,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -133274,33 +131513,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -133323,9 +131568,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -133334,15 +131579,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -133353,21 +131598,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -133375,18 +131608,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -133397,9 +131628,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -133407,21 +131650,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -133432,7 +131681,49 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>id</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -133450,15 +131741,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -133481,9 +131772,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -133492,9 +131783,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractID</TD> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -133541,15 +131832,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -133560,56 +131851,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> @@ -133626,15 +131870,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -133657,9 +131901,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -133668,41 +131912,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>hash</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -133713,21 +131956,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -133738,20 +131974,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -133762,39 +131993,56 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -133805,15 +132053,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> @@ -133828,9 +132076,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -133852,15 +132100,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -133871,76 +132119,13 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> +</TABLE> </TD> </TR> @@ -133955,63 +132140,71 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which the records should be retrieved</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -134034,87 +132227,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>cryptoGetInfo</TD> -<TD><a href="#CryptoGetInfoQuery">CryptoGetInfoQuery</a></TD> -<TD><P>Get all information about an account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Get all the information about an account, including the balance. This does not get the list of account records. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -134125,34 +132275,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -134163,51 +132300,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -134218,23 +132341,17 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -134242,13 +132359,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -134288,21 +132413,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> +<TD>sendRecordThreshold</TD> <TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -134324,64 +132461,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -134394,42 +132482,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> -</TR> - -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -134438,34 +132491,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -134487,27 +132521,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -134704,28 +132732,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TD> </TR> - <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -134736,38 +132757,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -134778,45 +132776,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -134825,15 +132799,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -134855,39 +132829,32 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -134898,15 +132865,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -134929,9 +132896,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -134940,33 +132907,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -134977,21 +132937,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -135002,37 +132956,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -135043,50 +132994,59 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135097,15 +133057,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -135128,45 +133088,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -135175,15 +133099,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -135423,15 +133347,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -135442,26 +133371,28 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -135472,49 +133403,29 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135525,15 +133436,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135544,21 +133466,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -135567,7 +133483,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -135585,15 +133501,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135604,38 +133539,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -135658,9 +133570,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -135668,42 +133580,27 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135714,15 +133611,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135733,21 +133630,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -135755,16 +133646,10 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -135789,7 +133674,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -135944,15 +133829,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -135963,36 +133854,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -136003,20 +133884,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> @@ -136206,24 +134104,42 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -136246,9 +134162,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -136256,34 +134172,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136294,26 +134197,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -136326,7 +134218,19 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -136335,15 +134239,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136354,15 +134258,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -136371,15 +134275,34 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -136501,20 +134424,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -136525,6 +134446,8 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -136534,15 +134457,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136553,44 +134487,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> <table class="field-table"> <thead> <TR> @@ -136601,15 +134505,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -136632,9 +134536,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -136643,15 +134547,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -136674,9 +134578,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -136686,38 +134590,16 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -136728,21 +134610,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -136750,27 +134620,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136781,15 +134645,14 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -136800,15 +134663,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -136819,15 +134682,38 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -136850,20 +134736,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -136873,24 +134748,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136901,15 +134773,44 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -136920,38 +134821,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -137149,15 +135033,52 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -137180,9 +135101,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -137191,20 +135112,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -137215,28 +135149,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -137247,29 +135174,37 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -137280,26 +135215,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -137312,13 +135260,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -137327,14 +135269,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -137345,34 +135288,43 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -137383,15 +135335,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -137414,20 +135366,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -137436,34 +135377,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -137491,34 +135419,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -137640,18 +135549,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -137662,8 +135573,6 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -137673,21 +135582,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -137698,62 +135601,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -137948,23 +135828,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -137975,15 +135850,26 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -138006,9 +135892,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -138022,15 +135908,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -138041,15 +135927,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -138072,26 +135958,31 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -138102,15 +135993,40 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -138119,34 +136035,41 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> -</thead> + <tbody> +</TABLE> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -138157,14 +136080,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -138175,15 +136105,20 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -138194,56 +136129,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -138254,15 +136172,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> @@ -138277,617 +136195,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> -</TR> - -<TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -138917,7 +136227,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -138936,7 +136246,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -139020,7 +136330,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -139060,15 +136370,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which information is requested</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -139091,9 +136401,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -139101,21 +136411,39 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the amount of gas to use for the call. All of the gas offered will be charged for.</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<TR> +<TD>maxResultSize</TD> +<TD>int64</TD> +<TD><P>max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes.</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoGetClaim</TD> -<TD><a href="#CryptoGetClaimQuery">CryptoGetClaimQuery</a></TD> -<TD><P>Get a single claim from a single account (or null if it doesn't exist)</P></TD> +<TD>contractGetInfo</TD> +<TD><a href="#ContractGetInfoQuery">ContractGetInfoQuery</a></TD> +<TD><P>Get information about a smart contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get a single claim attached to an account, or return null if it does not exist. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139128,7 +136456,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>header</TD> <TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> @@ -139153,7 +136481,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139190,7 +136518,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139228,7 +136556,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139359,7 +136687,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139419,7 +136747,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139503,7 +136831,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139564,7 +136892,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -139824,7 +137152,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139860,7 +137188,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -139926,7 +137254,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -140143,7 +137471,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -140204,7 +137532,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -140240,7 +137568,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -140488,7 +137816,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -140571,7 +137899,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -140741,7 +138069,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -140760,7 +138088,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -140846,7 +138174,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -141009,7 +138337,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141049,7 +138377,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141068,7 +138396,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -141340,7 +138668,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141370,7 +138698,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141436,7 +138764,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -141647,7 +138975,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141755,7 +139083,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141865,7 +139193,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -141947,7 +139275,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142008,7 +139336,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -142326,7 +139654,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142356,7 +139684,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142429,7 +139757,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142501,7 +139829,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142520,7 +139848,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142575,7 +139903,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -142744,7 +140072,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -142810,7 +140138,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -143021,7 +140349,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143087,7 +140415,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143148,7 +140476,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143203,7 +140531,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -143377,7 +140705,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143535,7 +140863,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143663,7 +140991,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -143709,27 +141037,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -143740,15 +141299,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -143816,7 +142298,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -143841,7 +142323,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -143908,7 +142390,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -143974,7 +142456,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -143993,7 +142475,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -144077,7 +142559,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -144117,15 +142599,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID to which the claim was attached</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -144148,9 +142630,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -144158,27 +142640,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>The hash of the claim</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoGetProxyStakers</TD> -<TD><a href="#CryptoGetStakersQuery">CryptoGetStakersQuery</a></TD> -<TD><P>Get all the accounts that proxy stake to a given account, and how much they proxy stake (not yet implemented in the current API)</P></TD> +<TD>contractGetBytecode</TD> +<TD><a href="#ContractGetBytecodeQuery">ContractGetBytecodeQuery</a></TD> +<TD><P>Get bytecode used by a smart contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144191,7 +142667,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD>header</TD> <TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD><P>standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> @@ -144216,7 +142692,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144253,7 +142729,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144291,7 +142767,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144422,7 +142898,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144482,7 +142958,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144566,7 +143042,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144627,7 +143103,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -144887,7 +143363,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144923,7 +143399,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -144989,7 +143465,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -145206,7 +143682,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -145267,7 +143743,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -145303,7 +143779,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -145551,7 +144027,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -145634,7 +144110,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -145804,7 +144280,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -145823,7 +144299,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -145909,7 +144385,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -146072,7 +144548,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146112,7 +144588,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146131,7 +144607,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -146403,7 +144879,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146433,7 +144909,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146499,7 +144975,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -146710,7 +145186,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146818,7 +145294,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -146928,7 +145404,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147010,7 +145486,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147071,7 +145547,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -147389,7 +145865,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147419,7 +145895,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147492,7 +145968,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147564,7 +146040,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147583,7 +146059,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147638,7 +146114,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -147807,7 +146283,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -147873,7 +146349,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -148084,7 +146560,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148150,7 +146626,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148211,7 +146687,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148266,7 +146742,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -148440,7 +146916,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148598,7 +147074,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148726,7 +147202,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -148772,27 +147248,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -148803,15 +147510,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -148879,7 +148509,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -148904,7 +148534,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -148971,7 +148601,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -149037,7 +148667,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -149056,7 +148686,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -149140,7 +148770,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -149180,15 +148810,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for which the records should be retrieved</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -149211,9 +148841,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -149227,15 +148857,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileGetContents</TD> -<TD><a href="#FileGetContentsQuery">FileGetContentsQuery</a></TD> -<TD><P>Get the contents of a file (the bytes stored in it)</P></TD> +<TD>ContractGetRecords</TD> +<TD><a href="#ContractGetRecordsQuery">ContractGetRecordsQuery</a></TD> +<TD><P>Get Records of the contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the contents of a file. The content field is empty (no bytes) if the file is empty. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149273,7 +148903,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149310,7 +148940,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149348,7 +148978,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149479,7 +149109,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149539,7 +149169,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149623,7 +149253,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149684,7 +149314,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -149944,7 +149574,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -149980,7 +149610,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150046,7 +149676,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -150263,7 +149893,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150324,7 +149954,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150360,7 +149990,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -150608,7 +150238,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150691,7 +150321,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150861,7 +150491,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -150880,7 +150510,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -150966,7 +150596,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -151129,7 +150759,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151169,7 +150799,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151188,7 +150818,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -151460,7 +151090,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151490,7 +151120,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151556,7 +151186,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -151767,7 +151397,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151875,7 +151505,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -151985,7 +151615,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152067,7 +151697,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152128,7 +151758,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -152446,7 +152076,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152476,7 +152106,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152549,7 +152179,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152621,7 +152251,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152640,7 +152270,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152695,7 +152325,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -152864,7 +152494,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -152930,7 +152560,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -153141,7 +152771,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153207,7 +152837,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153268,7 +152898,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153323,7 +152953,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -153497,7 +153127,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153655,7 +153285,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153783,7 +153413,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -153829,27 +153459,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -153860,15 +153721,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -153936,7 +154720,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -153961,7 +154745,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -154028,7 +154812,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -154094,7 +154878,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -154113,7 +154897,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -154197,7 +154981,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -154237,15 +155021,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file whose contents are requested</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The smart contract instance for which the records should be retrieved</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -154268,9 +155052,9 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -154284,15 +155068,15 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileGetInfo</TD> -<TD><a href="#FileGetInfoQuery">FileGetInfoQuery</a></TD> -<TD><P>Get information about a file, such as its expiration date</P></TD> +<TD>cryptogetAccountBalance</TD> +<TD><a href="#CryptoGetAccountBalanceQuery">CryptoGetAccountBalanceQuery</a></TD> +<TD><P>Get the current balance in a cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154330,7 +155114,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154367,7 +155151,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154405,7 +155189,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154536,7 +155320,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154596,7 +155380,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154680,7 +155464,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -154741,7 +155525,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -155001,7 +155785,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155037,7 +155821,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155103,7 +155887,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -155320,7 +156104,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155381,7 +156165,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155417,7 +156201,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -155665,7 +156449,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155748,7 +156532,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -155918,7 +156702,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -155937,7 +156721,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156023,7 +156807,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -156186,7 +156970,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156226,7 +157010,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156245,7 +157029,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -156517,7 +157301,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156547,7 +157331,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156613,7 +157397,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -156824,7 +157608,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -156932,7 +157716,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157042,7 +157826,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157124,7 +157908,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157185,7 +157969,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -157503,7 +158287,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157533,7 +158317,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157606,7 +158390,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157678,7 +158462,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157697,7 +158481,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157752,7 +158536,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -157921,7 +158705,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -157987,7 +158771,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -158198,7 +158982,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158264,7 +159048,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158325,7 +159109,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158380,7 +159164,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -158554,7 +159338,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158712,7 +159496,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158840,7 +159624,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -158886,27 +159670,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -158917,15 +159932,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -158993,7 +160931,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -159018,7 +160956,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -159085,7 +161023,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -159151,7 +161089,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -159170,7 +161108,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -159254,7 +161192,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -159294,15 +161232,33 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file for which information is requested</P></TD> +<TD>balanceSource</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID for which information is requested</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -159325,9 +161281,51 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The account ID for which information is requested</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -159337,19 +161335,21 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>transactionGetReceipt</TD> -<TD><a href="#TransactionGetReceiptQuery">TransactionGetReceiptQuery</a></TD> -<TD><P>Get a receipt for a transaction (lasts 180 seconds)</P></TD> +<TD>cryptoGetAccountRecords</TD> +<TD><a href="#CryptoGetAccountRecordsQuery">CryptoGetAccountRecordsQuery</a></TD> +<TD><P>Get all the records that currently exist for transactions involving an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159387,7 +161387,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159424,7 +161424,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159462,7 +161462,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159593,7 +161593,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159653,7 +161653,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159737,7 +161737,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -159798,7 +161798,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -160058,7 +162058,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160094,7 +162094,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160160,7 +162160,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -160377,7 +162377,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160438,7 +162438,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160474,7 +162474,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -160722,7 +162722,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160805,7 +162805,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -160975,7 +162975,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -160994,7 +162994,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161080,7 +163080,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -161243,7 +163243,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161283,7 +163283,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161302,7 +163302,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -161574,7 +163574,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161604,7 +163604,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161670,7 +163670,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -161881,7 +163881,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -161989,7 +163989,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162099,7 +164099,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162181,7 +164181,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162242,7 +164242,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -162560,7 +164560,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162590,7 +164590,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162663,7 +164663,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162735,7 +164735,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162754,7 +164754,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -162809,7 +164809,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -162978,7 +164978,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163044,7 +165044,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -163255,7 +165255,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163321,7 +165321,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163382,7 +165382,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163437,7 +165437,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -163611,7 +165611,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163769,7 +165769,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163897,7 +165897,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -163943,27 +165943,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -163974,15 +166205,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -164050,7 +167204,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -164075,7 +167229,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -164142,7 +167296,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -164208,7 +167362,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -164227,7 +167381,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -164311,7 +167465,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -164348,67 +167502,12 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction for which the receipt is requested.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>The account ID for which the records should be retrieved</P></TD> </TR> <TR> @@ -164450,23 +167549,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>transactionGetRecord</TD> -<TD><a href="#TransactionGetRecordQuery">TransactionGetRecordQuery</a></TD> -<TD><P>Get a record for a transaction (lasts 1 hour)</P></TD> +<TD>cryptoGetInfo</TD> +<TD><a href="#CryptoGetInfoQuery">CryptoGetInfoQuery</a></TD> +<TD><P>Get all information about an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164504,7 +167598,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164541,7 +167635,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164579,7 +167673,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164710,7 +167804,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164770,7 +167864,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164854,7 +167948,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -164915,7 +168009,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -165175,7 +168269,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -165211,7 +168305,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -165277,7 +168371,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -165494,7 +168588,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -165555,7 +168649,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -165591,7 +168685,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -165839,7 +168933,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -165922,7 +169016,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166092,7 +169186,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -166111,7 +169205,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166197,7 +169291,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -166360,7 +169454,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166400,7 +169494,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166419,7 +169513,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -166691,7 +169785,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166721,7 +169815,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -166787,7 +169881,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -166998,7 +170092,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167106,7 +170200,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167216,7 +170310,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167298,7 +170392,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167359,7 +170453,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -167677,7 +170771,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167707,7 +170801,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167780,7 +170874,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167852,7 +170946,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167871,7 +170965,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -167926,7 +171020,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -168095,7 +171189,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -168161,7 +171255,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -168372,7 +171466,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -168438,7 +171532,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -168499,7 +171593,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -168554,7 +171648,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -168728,7 +171822,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -168886,7 +171980,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169014,7 +172108,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169060,27 +172154,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -169091,15 +172416,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -169167,7 +173415,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -169192,7 +173440,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -169259,7 +173507,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -169325,7 +173573,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -169344,7 +173592,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -169428,7 +173676,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -169465,67 +173713,12 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction for which the record is requested.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>The account ID for which information is requested</P></TD> </TR> <TR> @@ -169567,23 +173760,18 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>transactionGetFastRecord</TD> -<TD><a href="#TransactionGetFastRecordQuery">TransactionGetFastRecordQuery</a></TD> -<TD><P>Get a record for a transaction (lasts 180 seconds)</P></TD> +<TD>cryptoGetClaim</TD> +<TD><a href="#CryptoGetClaimQuery">CryptoGetClaimQuery</a></TD> +<TD><P>Get a single claim from a single account (or null if it doesn't exist)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169621,7 +173809,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169658,7 +173846,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169696,7 +173884,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169827,7 +174015,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169887,7 +174075,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -169971,7 +174159,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -170032,7 +174220,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -170292,7 +174480,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -170328,7 +174516,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -170394,7 +174582,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -170611,7 +174799,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -170672,7 +174860,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -170708,7 +174896,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -170956,7 +175144,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171039,7 +175227,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171209,7 +175397,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -171228,7 +175416,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171314,7 +175502,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -171477,7 +175665,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171517,7 +175705,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171536,7 +175724,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -171808,7 +175996,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171838,7 +176026,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -171904,7 +176092,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -172115,7 +176303,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172223,7 +176411,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172333,7 +176521,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172415,7 +176603,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172476,7 +176664,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -172794,7 +176982,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172824,7 +177012,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172897,7 +177085,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172969,7 +177157,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -172988,7 +177176,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -173043,7 +177231,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -173212,7 +177400,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -173278,7 +177466,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -173489,7 +177677,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -173555,7 +177743,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -173616,7 +177804,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -173671,7 +177859,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -173845,7 +178033,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174003,7 +178191,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174131,7 +178319,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174177,27 +178365,258 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -174208,15 +178627,938 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -174284,7 +179626,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -174309,7 +179651,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -174376,7 +179718,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -174442,7 +179784,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -174461,7 +179803,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -174545,7 +179887,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -174582,67 +179924,12 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <tbody> </TABLE> -</TD> -</TR> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction for which the record is requested.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - </TD> </TR> <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>The account ID to which the claim was attached</P></TD> </TR> <TR> @@ -174681,32 +179968,45 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>The hash of the claim</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>consensusGetTopicInfo</TD> -<TD><a href="#ConsensusGetTopicInfoQuery">ConsensusGetTopicInfoQuery</a></TD> -<TD><P>Get the parameters of and state of a consensus topic.</P></TD> +<TD>cryptoGetProxyStakers</TD> +<TD><a href="#CryptoGetStakersQuery">CryptoGetStakersQuery</a></TD> +<TD><P>Get all the accounts that proxy stake to a given account, and how much they proxy stake (not yet implemented in the current API)</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +</TR> -<div class="file-heading"> -<H2 id="QueryHeader.proto">QueryHeader.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> +<TR> +<TD> </TD> +<TD colspan=2> <P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> @@ -174726,7 +180026,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174763,7 +180063,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174801,7 +180101,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174932,7 +180232,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -174992,7 +180292,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175076,7 +180376,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175137,7 +180437,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -175397,7 +180697,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175433,7 +180733,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175499,7 +180799,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -175716,7 +181016,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175777,7 +181077,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -175813,7 +181113,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -176061,7 +181361,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176144,7 +181444,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176314,7 +181614,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -176333,7 +181633,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176419,7 +181719,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -176582,7 +181882,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176622,7 +181922,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176641,7 +181941,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -176913,7 +182213,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -176943,7 +182243,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177009,7 +182309,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -177220,7 +182520,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177328,7 +182628,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177438,7 +182738,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177520,7 +182820,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177581,7 +182881,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -177899,7 +183199,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -177929,7 +183229,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178002,7 +183302,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178074,7 +183374,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178093,7 +183393,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178148,7 +183448,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -178317,7 +183617,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178383,7 +183683,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -178594,7 +183894,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178660,7 +183960,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178721,7 +184021,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -178776,7 +184076,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -178950,7 +184250,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -179108,7 +184408,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -179236,7 +184536,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -179282,27 +184582,258 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> <table class="field-table"> <thead> <TR> @@ -179313,15 +184844,15 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -179344,9 +184875,9 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -179355,41 +184886,33 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TD> </TR> <TR> -<TD>message</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>bodyBytes</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -179400,21 +184923,21 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -179425,20 +184948,37 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -179449,39 +184989,39 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -179492,42 +185032,53 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> + <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> + <tbody> </TABLE> @@ -179539,15 +185090,15 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -179558,15 +185109,15 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -179577,20 +185128,44 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -179601,82 +185176,94 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -179684,48 +185271,59 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TD> </TR> -<tbody> -</TABLE> - -<H3 id="ResponseType"><span class="BigBadge">Enum</span>ResponseType</H3> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> -<thead> <TR> -<TD>Enum Name</TD> -<TD>Description</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> -<div class="file-heading"> -<H2 id="Response.proto">Response.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="Response"><span class="BigBadge">Message</span>Response</H3> -<P> A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. </P> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -179736,14 +185334,37 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>response</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -179754,15 +185375,39 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>getByKey</TD> -<TD><a href="#GetByKeyResponse">GetByKeyResponse</a></TD> -<TD><P>Get all entities associated with a given key</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node GetByKeyQuery </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -179773,15 +185418,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -179792,664 +185436,991 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TD> </TR> - <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>Enum Name</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +</TD> </TR> - <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for which the records should be retrieved</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>fileGetContents</TD> +<TD><a href="#FileGetContentsQuery">FileGetContentsQuery</a></TD> +<TD><P>Get the contents of a file (the bytes stored in it)</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -180458,15 +186429,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cost</TD> +<TD>transactionFee</TD> <TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -180475,15 +186465,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>entities</TD> -<TD><a href="#EntityID">EntityID</a> (repeated)</TD> -<TD><P>The list of entities that include this public key in their associated Key list</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> <table class="field-table"> <thead> <TR> @@ -180494,14 +186495,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>entity</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -180512,15 +186514,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for the cryptocurrency account</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -180543,9 +186545,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -180554,15 +186556,38 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>The claim details attached to an account</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -180573,15 +186598,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -180604,9 +186629,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -180615,40 +186640,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -180770,18 +186770,20 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -180792,8 +186794,6 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -180803,15 +186803,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -180822,11 +186822,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -180834,19 +186840,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -180869,9 +186889,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -180880,15 +186900,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract ID that identifies instance</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -180899,21 +186919,45 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> -<TD>contractNum</TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -180921,28 +186965,52 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>getBySolidityID</TD> -<TD><a href="#GetBySolidityIDResponse">GetBySolidityIDResponse</a></TD> -<TD><P>Get the IDs in the format used in transactions, given the format used in Solidity</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node GetBySolidityIDQuery </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -180953,15 +187021,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -180972,621 +187039,727 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TD> </TR> - <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD>obtainers</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -181595,69 +187768,96 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID for the cryptocurrency account</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -181697,15 +187897,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file Id for the file</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -181716,32 +187922,46 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>A smart contract ID for the instance (if this is included, then the associated accountID will also be included)</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -181780,21 +188000,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> + <TR> -<TD>contractCallLocal</TD> -<TD><a href="#ContractCallLocalResponse">ContractCallLocalResponse</a></TD> -<TD><P>Response to call a function of a smart contract instance</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractCallLocalQuery </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -181805,640 +188038,744 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> -<table class="field-table"> -<thead> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TD> </TR> - <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TD> </TR> - <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> - <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TD> </TR> - <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TD> </TR> - <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -182447,41 +188784,40 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -182489,33 +188825,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>functionResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>the value returned by the function (if it completed and didn't fail)</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -182526,15 +188850,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -182557,9 +188881,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -182568,39 +188892,64 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -182611,15 +188960,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -182642,9 +188991,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -182653,21 +189002,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> <tbody> @@ -182686,15 +189023,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractGetBytecodeResponse</TD> -<TD><a href="#ContractGetBytecodeResponse">ContractGetBytecodeResponse</a></TD> -<TD><P>Get the bytecode for a smart contract instance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractGetBytecodeQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -182705,15 +189042,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -182724,664 +189061,787 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TD> </TR> - <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +</TD> </TR> - <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TD> </TR> - <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TD> </TR> - <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -183390,26 +189850,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> + <TR> -<TD>bytecode</TD> -<TD>bytes</TD> -<TD><P>the bytecode</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -183418,15 +189886,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractGetInfo</TD> -<TD><a href="#ContractGetInfoResponse">ContractGetInfoResponse</a></TD> -<TD><P>Get information about a smart contract instance</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractGetInfoQuery </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -183437,15 +189905,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -183456,664 +189923,862 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +</TD> </TR> - <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> - <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -184122,32 +190787,58 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> -</TD> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>contractInfo</TD> -<TD><a href="#ContractGetInfoResponse.ContractInfo">ContractGetInfoResponse.ContractInfo</a></TD> -<TD><P>the information about this contract instance (a state proof can be generated for this)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractGetInfoQuery </P> <table class="field-table"> <thead> <TR> @@ -184160,7 +190851,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>ID of the contract instance, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -184200,15 +190891,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -184219,44 +190928,105 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>adminKey</TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -184454,15 +191224,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -184475,13 +191245,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -184490,15 +191254,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -184509,32 +191273,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>storage</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance, in tinybars</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -184548,15 +191301,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractGetRecordsResponse</TD> -<TD><a href="#ContractGetRecordsResponse">ContractGetRecordsResponse</a></TD> -<TD><P>Get all existing records for a smart contract instance</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node ContractGetRecordsQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -184567,15 +191320,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -184586,623 +191339,968 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> - <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> +<TD>signature</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> @@ -185211,13 +192309,13 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>responseType</TD> <TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -185251,33 +192349,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The smart contract instance that this record is for</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file whose contents are requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -185300,26 +192386,31 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>records</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> -<TD><P>List of records, each with contractCreateResult or contractCallResult as its body</P></TD> +<TD>fileGetInfo</TD> +<TD><a href="#FileGetInfoQuery">FileGetInfoQuery</a></TD> +<TD><P>Get information about a file, such as its expiration date</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -185330,15 +192421,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -185349,621 +192440,735 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +</TD> </TR> - <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TD> </TR> - <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TD> </TR> - <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -185972,15 +193177,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -186002,27 +193207,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -186033,32 +193232,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -186098,34 +193292,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Two sets of exchange rate </P> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -186136,27 +193329,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -186167,11 +193354,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -186183,15 +193376,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -186202,42 +193395,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -186245,24 +193413,51 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -186285,26 +193480,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -186313,21 +193491,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>transactionHash</TD> -<TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> -</TR> - -<TR> -<TD>consensusTimestamp</TD> +<TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -186355,15 +193527,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -186374,15 +193546,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> <table class="field-table"> <thead> <TR> @@ -186393,32 +193564,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -186441,9 +193595,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -186451,32 +193605,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> + <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -186487,15 +193643,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -186506,15 +193668,37 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -186525,62 +193709,81 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -186591,15 +193794,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -186622,9 +193836,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -186633,43 +193847,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -186682,7 +193879,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> @@ -186722,39 +193919,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> - -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> -</TR> - -<TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> <table class="field-table"> <thead> <TR> @@ -186765,15 +193937,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -186796,9 +193968,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -186807,21 +193979,40 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -186831,21 +194022,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -186856,15 +194047,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -186877,7 +194068,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -186917,41 +194108,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptogetAccountBalance</TD> -<TD><a href="#CryptoGetAccountBalanceResponse">CryptoGetAccountBalanceResponse</a></TD> -<TD><P>Get the current balance in a cryptocurrency account</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetAccountBalanceQuery </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -186962,15 +194133,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -186981,621 +194152,841 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> - <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TD> </TR> - <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TD> </TR> - <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +</TD> </TR> - <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -187604,69 +194995,75 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> +<TD>accountIDToDeleteFrom</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that is being described (this is useful with state proofs, for proving to a third party)</P></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> @@ -187706,9 +195103,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance, in tinybars</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> <tbody> @@ -187717,15 +195114,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cryptoGetAccountRecords</TD> -<TD><a href="#CryptoGetAccountRecordsResponse">CryptoGetAccountRecordsResponse</a></TD> -<TD><P>Get all the records that currently exist for transactions involving an account</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetAccountRecordsQuery </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -187736,15 +195133,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -187755,681 +195152,907 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +</TD> </TR> - <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TD> </TR> - <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> 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. </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -188438,15 +196061,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account that this record is for</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -188468,27 +196091,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>records</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> -<TD><P>List of records, each with CryptoRecordBody as their body</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -188499,15 +196116,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> <table class="field-table"> <thead> <TR> @@ -188518,638 +196134,703 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +</TD> </TR> - <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> - <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> - <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TD> </TR> - <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +</TD> </TR> - <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TD> </TR> - <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +</TD> </TR> - +<tbody> +</TABLE> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -189160,32 +196841,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -189227,7 +196903,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -189264,18 +196940,25 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -189286,46 +196969,44 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>hbarEquiv</TD> +<TD>endHour</TD> <TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>centEquiv</TD> +<TD>endMin</TD> <TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -189336,31 +197017,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -189371,27 +197042,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -189402,36 +197060,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -189454,9 +197091,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -189465,38 +197102,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionHash</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -189507,32 +197139,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -189543,51 +197164,37 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -189598,23 +197205,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -189622,30 +197223,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> -</TR> - -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> -</TR> - -<TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -189656,15 +197248,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -189677,7 +197268,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -189717,39 +197308,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -189760,15 +197345,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -189779,46 +197370,58 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -189826,19 +197429,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -189849,15 +197454,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -189880,9 +197496,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -189890,40 +197506,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +</TD> </TR> - <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -189934,15 +197531,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -189965,9 +197562,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -189976,45 +197573,57 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -190025,15 +197634,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -190044,15 +197652,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -190075,9 +197683,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -190086,41 +197694,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoGetInfo</TD> -<TD><a href="#CryptoGetInfoResponse">CryptoGetInfoResponse</a></TD> -<TD><P>Get all information about an account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetInfoQuery </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -190131,15 +197731,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -190150,623 +197756,762 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> -<thead> -<TR> -<TD>Enum Name</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> -</TR> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> +<TD>signature</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> @@ -190775,13 +198520,13 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>responseType</TD> <TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -190815,52 +198560,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountInfo</TD> -<TD><a href="#CryptoGetInfoResponse.AccountInfo">CryptoGetInfoResponse.AccountInfo</a></TD> -<TD><P>Info about the account (a state proof can be generated for this)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Response when the client sends the node CryptoGetInfoQuery </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID for which this information applies</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file for which information is requested</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -190883,9 +198597,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -190893,28 +198607,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>contractAccountID</TD> -<TD>string</TD> -<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> +</TD> </TR> - <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID of the account to which this 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.</P></TD> +<TD>transactionGetReceipt</TD> +<TD><a href="#TransactionGetReceiptQuery">TransactionGetReceiptQuery</a></TD> +<TD><P>Get a receipt for a transaction (lasts 180 seconds)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -190925,44 +198632,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>proxyReceived</TD> -<TD>int64</TD> -<TD><P>The total number of tinybars proxy staked to this account</P></TD> -</TR> - <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -190973,7 +198670,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>key</TD> +<TD>bodyData</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -190991,15 +198688,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191010,56 +198707,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191070,21 +198745,32 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -191095,17 +198781,23 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> @@ -191117,15 +198809,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -191136,63 +198828,44 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>balance</TD> -<TD>uint64</TD> -<TD><P>The current balance of account in tinybars</P></TD> -</TR> - -<TR> -<TD>generateSendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> -</TR> - -<TR> -<TD>generateReceiveRecordThreshold</TD> +<TD>transactionFee</TD> <TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The TimeStamp time at which this account is set to expire</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191205,13 +198878,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -191220,15 +198887,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -191239,26 +198917,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>claims</TD> -<TD><a href="#Claim">Claim</a> (repeated)</TD> -<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191269,15 +198936,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -191300,9 +198967,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -191311,21 +198978,38 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>hash</TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191336,15 +199020,57 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -191466,18 +199192,20 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -191488,8 +199216,6 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -191499,15 +199225,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -191518,14 +199244,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> -<tbody> -</TABLE> - +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -191535,24 +199262,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoGetClaim</TD> -<TD><a href="#CryptoGetClaimResponse">CryptoGetClaimResponse</a></TD> -<TD><P>Get a single claim from a single account (or null if it doesn't exist)</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetClaimQuery. If the claim exists, there can be a state proof for that single claim. If the claim doesn't exist, then the state proof must be obtained for the account as a whole, which lists all the attached claims, which then proves that any claim not on the list must not exist. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -191563,15 +199299,38 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -191582,621 +199341,847 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> <P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +</TD> </TR> - <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -192205,75 +200190,83 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>claim</TD> <TD><a href="#Claim">Claim</a></TD> -<TD><P>The claim (account, hash, keys), or null if there is no Claim with the given hash attached to the given account</P></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -192359,7 +200352,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -192522,7 +200515,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -192554,15 +200547,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cryptoGetProxyStakers</TD> -<TD><a href="#CryptoGetStakersResponse">CryptoGetStakersResponse</a></TD> -<TD><P>Get all the accounts that proxy stake to a given account, and how much they proxy stake</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node CryptoGetStakersQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -192573,15 +200566,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -192592,698 +200585,575 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - -<TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> -</TR> - -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> -</TR> - -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> - -<TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - -<TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - -<TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - -<TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> - -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> -</TR> - -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> - -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> -</TR> - -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> -</TR> - -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> -</TR> - -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> -</TR> - -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> -</TR> - -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> -</TR> - -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - -<TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - -<TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TD> </TR> - <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TD> </TR> - <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> A list of keys </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> - -<TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>stakers</TD> -<TD><a href="#AllProxyStakers">AllProxyStakers</a></TD> -<TD><P>List of accounts proxy staking to this account, and the amount each is currently proxy staking</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -193294,9 +201164,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is being proxy staked to</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -193336,28 +201206,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>proxyStaker</TD> -<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> -<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> information about a single account that is proxy staking </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> +<TD>deleteAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that is proxy staking</P></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> @@ -193396,37 +201247,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>The number of hbars that are currently proxy staked</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileGetContents</TD> -<TD><a href="#FileGetContentsResponse">FileGetContentsResponse</a></TD> -<TD><P>Get the contents of a file (the bytes stored in it)</P></TD> +<TR> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node FileGetContentsQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -193437,15 +201272,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -193456,664 +201291,695 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="enum-table"> -<thead> -<TR> -<TD>Enum Name</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TD> </TR> - <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> - <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TD> </TR> - <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> -</TR> - -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a file </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -194122,15 +201988,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> <tbody> @@ -194139,15 +201999,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>fileContents</TD> -<TD><a href="#FileGetContentsResponse.FileContents">FileGetContentsResponse.FileContents</a></TD> -<TD><P>the file ID and contents (a state proof can be generated for this)</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node FileGetContentsQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -194158,15 +202018,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file whose contents are being returned</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -194177,21 +202037,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -194200,31 +202054,34 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes contained in the file</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>fileGetInfo</TD> -<TD><a href="#FileGetInfoResponse">FileGetInfoResponse</a></TD> -<TD><P>Get information about a file, such as its expiration date</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node FileGetInfoQuery </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -194235,15 +202092,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -194254,621 +202110,842 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> - <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> +<TD>id</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -194877,41 +202954,40 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -194919,33 +202995,71 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>fileInfo</TD> -<TD><a href="#FileGetInfoResponse.FileInfo">FileGetInfoResponse.FileInfo</a></TD> -<TD><P>The information about the file (a state proof can be generated for this)</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node FileGetInfoQuery </P> <table class="field-table"> <thead> <TR> @@ -194958,7 +203072,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file for which information is requested</P></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -194998,21 +203112,64 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>size</TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of bytes in contents</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The current time at which this account is set to expire</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -195023,15 +203180,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>nanos</TD> +<TD>startMin</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -195040,21 +203209,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>deleted</TD> -<TD>bool</TD> -<TD><P>True if deleted but not yet expired</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -195065,15 +203228,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -195192,6 +203361,25 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -195201,6 +203389,11 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -195212,14 +203405,26 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -195229,24 +203434,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionGetReceipt</TD> -<TD><a href="#TransactionGetReceiptResponse">TransactionGetReceiptResponse</a></TD> -<TD><P>Get a receipt for a transaction (lasts 180 seconds)</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetReceiptQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. No State proof is available for this response </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -195257,15 +203459,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -195276,664 +203477,897 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +</TD> </TR> - <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +</TD> </TR> - <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -195941,33 +204375,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The receipt, indicating it reached consensus (and whether it succeeded or failed) or is currently unknown (because it hasn't reached consensus yet, or the transaction has expired already), and including the ID of any new account/file/instance created by that transaction.</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -195978,638 +204400,822 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>Enum Name</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction for which the receipt is requested.</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>transactionGetRecord</TD> +<TD><a href="#TransactionGetRecordQuery">TransactionGetRecordQuery</a></TD> +<TD><P>Get a record for a transaction (lasts 1 hour)</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> +<TD>data</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -196632,9 +205238,32 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> @@ -196643,9 +205272,28 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> @@ -196685,9 +205333,46 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -196727,15 +205412,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -196746,15 +205449,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -196765,27 +205474,37 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -196796,11 +205515,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -196808,19 +205533,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -196831,27 +205570,38 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -196864,7 +205614,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -196872,26 +205622,22 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -196904,19 +205650,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -196925,37 +205659,51 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionGetRecord</TD> -<TD><a href="#TransactionGetRecordResponse">TransactionGetRecordResponse</a></TD> -<TD><P>Get a record for a transaction (lasts 1 hour)</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordQuery </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -196966,15 +205714,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> <table class="field-table"> <thead> <TR> @@ -196985,621 +205732,727 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +</TD> </TR> - <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +</TD> </TR> - <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +</TD> </TR> - <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TD> </TR> - <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TD> </TR> - <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TD> </TR> - <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TD> </TR> - <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> +<TD>obtainers</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -197608,41 +206461,40 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> -</TR> - -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -197650,33 +206502,23 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> -</TR> - -<TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>transactionRecord</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a></TD> -<TD><P>The requested record</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -197687,15 +206529,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -197706,638 +206548,285 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - -<TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> - -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> - -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> -</TR> - -<TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> -</TR> - -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> -</TR> - -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> -</TR> - -<TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - -<TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> -</TR> - -<TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> -</TR> - -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - -<TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> - -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> - -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - -<TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - -<TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> -</TR> - -<TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> -</TR> - -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - -<TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - -<TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> -</TR> - -<TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> - -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> - -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> -</TR> - -<TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> -</TR> - -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - -<TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> - -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - -<TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> - -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> -</TR> - -<TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> -</TR> - -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> -</TR> - -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> - -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - -<TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> -</TR> - -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - -<TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> -</TR> - -<TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - -<TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> -</TR> - -<TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - -<TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - -<TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> -</TR> - -<TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> - -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - -<TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> -</TR> - -<TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - -<TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - -<TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -198348,38 +206837,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -198390,32 +206856,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -198455,34 +206916,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Two sets of exchange rate </P> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -198493,27 +206953,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -198524,11 +206978,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -198540,15 +207000,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -198559,42 +207019,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -198602,24 +207037,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -198642,9 +207080,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -198653,38 +207091,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> +<TD>sendRecordThreshold</TD> <TD>uint64</TD> -<TD><P></P></TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionHash</TD> -<TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -198697,13 +207130,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -198712,34 +207139,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -198750,15 +207158,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -198767,15 +207169,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -198797,43 +207199,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> -</TR> - -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> -</TR> - -<TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -198844,15 +207224,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -198865,7 +207244,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -198905,39 +207284,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -198948,15 +207321,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -198967,46 +207346,65 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> @@ -199018,15 +207416,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -199037,15 +207435,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -199068,9 +207466,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -199079,39 +207477,62 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -199122,15 +207543,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -199153,9 +207574,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -199164,21 +207585,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> +<TD>hashToDelete</TD> <TD>bytes</TD> -<TD><P>event data</P></TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> <tbody> @@ -199186,17 +207595,29 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> <TR> -<TD>transferList</TD> +<TD>transfers</TD> <TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> @@ -199221,7 +207642,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -199292,23 +207713,18 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>transactionGetFastRecord</TD> -<TD><a href="#TransactionGetFastRecordResponse">TransactionGetFastRecordResponse</a></TD> -<TD><P>Get a record for a transaction (lasts 180 seconds)</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -199319,15 +207735,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -199338,681 +207754,823 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> +</TR> + +<TR> +<TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TD> </TR> - <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +</TD> </TR> - <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> -<TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TD> </TR> - <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P></P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -200021,15 +208579,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>transactionRecord</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a></TD> -<TD><P>The requested transaction records</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -200040,15 +208598,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> <table class="field-table"> <thead> <TR> @@ -200059,638 +208616,703 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TD> </TR> - <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +</TD> </TR> - <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +</TD> </TR> - <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> - <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TD> </TR> - <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> </TR> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +</TD> </TR> - <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> -<TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TD> </TR> - <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +</TD> </TR> - +<tbody> +</TABLE> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -200701,32 +209323,27 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -200768,7 +209385,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -200805,18 +209422,25 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -200827,46 +209451,44 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>hbarEquiv</TD> +<TD>endHour</TD> <TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>centEquiv</TD> +<TD>endMin</TD> <TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -200877,31 +209499,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -200912,27 +209524,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -200943,36 +209542,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -200995,9 +209573,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -201006,38 +209584,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionHash</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -201048,32 +209621,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -201084,51 +209646,37 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -201139,23 +209687,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -201163,30 +209705,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> -</TR> - -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> -</TR> - -<TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -201197,15 +209730,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -201218,7 +209750,7 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -201258,39 +209790,33 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -201301,15 +209827,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -201320,46 +209852,17 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> -</TR> - <tbody> </TABLE> @@ -201371,15 +209874,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -201390,15 +209893,69 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -201421,9 +209978,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -201431,40 +209988,21 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> -<TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> -</TR> - -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +</TD> </TR> - <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -201475,15 +210013,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -201506,9 +210044,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -201517,45 +210055,57 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -201566,15 +210116,14 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -201585,15 +210134,15 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -201616,9 +210165,9 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -201627,665 +210176,736 @@ <H3 id="Response"><span class="BigBadge">Message</span>Response</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>consensusGetTopicInfo</TD> -<TD><a href="#ConsensusGetTopicInfoResponse">ConsensusGetTopicInfoResponse</a></TD> -<TD><P>Parameters of and state of a consensus topic..</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="ResponseCode.proto">ResponseCode.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ResponseCodeEnum"><span class="BigBadge">Enum</span>ResponseCodeEnum</H3> -<P></P> -<table class="enum-table"> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +</TD> </TR> - <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TD> </TR> - <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TD> </TR> - <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> -<TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> -<TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +</TD> </TR> - <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> +<tbody> +</TABLE> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +</TD> </TR> - <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +</TD> </TR> - <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="ResponseHeader.proto">ResponseHeader.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -202296,621 +210916,46422 @@ <H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> -</TR> - -<TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction for which the record is requested.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionGetFastRecord</TD> +<TD><a href="#TransactionGetFastRecordQuery">TransactionGetFastRecordQuery</a></TD> +<TD><P>Get a record for a transaction (lasts 180 seconds)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> +</TR> + +<TR> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction for which the record is requested.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusGetTopicInfo</TD> +<TD><a href="#ConsensusGetTopicInfoQuery">ConsensusGetTopicInfoQuery</a></TD> +<TD><P>Get the parameters of and state of a consensus topic.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P> Standard info sent from client to node, including the signed payment, and what kind of response is requested<BR>(cost, state proof, both, or neither).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> +</TR> + +<TR> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to retrieve info about (the parameters and running state of).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="QueryHeader.proto">QueryHeader.proto</H2> +<a href="#title">Top</a> +</div> +<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of GetInfo request. </P> +<H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> +</TR> + +<TR> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<H3 id="ResponseType"><span class="BigBadge">Enum</span>ResponseType</H3> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="Response.proto">Response.proto</H2> +<a href="#title">Top</a> +</div> +<P> A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. </P> +<H3 id="Response"><span class="BigBadge">Message</span>Response</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>response</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>getByKey</TD> +<TD><a href="#GetByKeyResponse">GetByKeyResponse</a></TD> +<TD><P>Get all entities associated with a given key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node GetByKeyQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>entities</TD> +<TD><a href="#EntityID">EntityID</a> (repeated)</TD> +<TD><P>The list of entities that include this public key in their associated Key list</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> the ID for a single entity (account, claim, file, or smart contract instance) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>entity</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for the cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>The claim details attached to an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The smart contract ID that identifies instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>getBySolidityID</TD> +<TD><a href="#GetBySolidityIDResponse">GetBySolidityIDResponse</a></TD> +<TD><P>Get the IDs in the format used in transactions, given the format used in Solidity</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node GetBySolidityIDQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID for the cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file Id for the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>A smart contract ID for the instance (if this is included, then the associated accountID will also be included)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallLocal</TD> +<TD><a href="#ContractCallLocalResponse">ContractCallLocalResponse</a></TD> +<TD><P>Response to call a function of a smart contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node ContractCallLocalQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>functionResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>the value returned by the function (if it completed and didn't fail)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractGetBytecodeResponse</TD> +<TD><a href="#ContractGetBytecodeResponse">ContractGetBytecodeResponse</a></TD> +<TD><P>Get the bytecode for a smart contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node ContractGetBytecodeQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bytecode</TD> +<TD>bytes</TD> +<TD><P>the bytecode</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractGetInfo</TD> +<TD><a href="#ContractGetInfoResponse">ContractGetInfoResponse</a></TD> +<TD><P>Get information about a smart contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node ContractGetInfoQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractInfo</TD> +<TD><a href="#ContractGetInfoResponse.ContractInfo">ContractGetInfoResponse.ContractInfo</a></TD> +<TD><P>the information about this contract instance (a state proof can be generated for this)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>ID of the contract instance, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>ID of the cryptocurrency account owned by the contract instance, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>the current time at which this contract instance (and its account) is set to expire</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>storage</TD> +<TD>int64</TD> +<TD><P>number of bytes of storage being used by this instance (which affects the cost to extend the expiration time)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance, in tinybars</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractGetRecordsResponse</TD> +<TD><a href="#ContractGetRecordsResponse">ContractGetRecordsResponse</a></TD> +<TD><P>Get all existing records for a smart contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node ContractGetRecordsQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The smart contract instance that this record is for</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>records</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> +<TD><P>List of records, each with contractCreateResult or contractCallResult as its body</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +</TR> + +<TR> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptogetAccountBalance</TD> +<TD><a href="#CryptoGetAccountBalanceResponse">CryptoGetAccountBalanceResponse</a></TD> +<TD><P>Get the current balance in a cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node CryptoGetAccountBalanceQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that is being described (this is useful with state proofs, for proving to a third party)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance, in tinybars</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoGetAccountRecords</TD> +<TD><a href="#CryptoGetAccountRecordsResponse">CryptoGetAccountRecordsResponse</a></TD> +<TD><P>Get all the records that currently exist for transactions involving an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node CryptoGetAccountRecordsQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account that this record is for</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>records</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a> (repeated)</TD> +<TD><P>List of records, each with CryptoRecordBody as their body</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +</TR> + +<TR> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoGetInfo</TD> +<TD><a href="#CryptoGetInfoResponse">CryptoGetInfoResponse</a></TD> +<TD><P>Get all information about an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node CryptoGetInfoQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountInfo</TD> +<TD><a href="#CryptoGetInfoResponse.AccountInfo">CryptoGetInfoResponse.AccountInfo</a></TD> +<TD><P>Info about the account (a state proof can be generated for this)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID for which this information applies</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractAccountID</TD> +<TD>string</TD> +<TD><P>The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity</P></TD> +</TR> + +<TR> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID of the account to which this 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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyReceived</TD> +<TD>int64</TD> +<TD><P>The total number of tinybars proxy staked to this account</P></TD> +</TR> + +<TR> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>balance</TD> +<TD>uint64</TD> +<TD><P>The current balance of account in tinybars</P></TD> +</TR> + +<TR> +<TD>generateSendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction.</P></TD> +</TR> + +<TR> +<TD>generateReceiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, no transaction can transfer to this account unless signed by this account's key</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The TimeStamp time at which this account is set to expire</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claims</TD> +<TD><a href="#Claim">Claim</a> (repeated)</TD> +<TD><P>All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it )</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoGetClaim</TD> +<TD><a href="#CryptoGetClaimResponse">CryptoGetClaimResponse</a></TD> +<TD><P>Get a single claim from a single account (or null if it doesn't exist)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node CryptoGetClaimQuery. If the claim exists, there can be a state proof for that single claim. If the claim doesn't exist, then the state proof must be obtained for the account as a whole, which lists all the attached claims, which then proves that any claim not on the list must not exist. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>The claim (account, hash, keys), or null if there is no Claim with the given hash attached to the given account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoGetProxyStakers</TD> +<TD><a href="#CryptoGetStakersResponse">CryptoGetStakersResponse</a></TD> +<TD><P>Get all the accounts that proxy stake to a given account, and how much they proxy stake</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node CryptoGetStakersQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>stakers</TD> +<TD><a href="#AllProxyStakers">AllProxyStakers</a></TD> +<TD><P>List of accounts proxy staking to this account, and the amount each is currently proxy staking</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that is being proxy staked to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyStaker</TD> +<TD><a href="#ProxyStaker">ProxyStaker</a> (repeated)</TD> +<TD><P>Each of the proxy staking accounts, and the amount they are proxy staking</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> information about a single account that is proxy staking </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that is proxy staking</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>The number of hbars that are currently proxy staked</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileGetContents</TD> +<TD><a href="#FileGetContentsResponse">FileGetContentsResponse</a></TD> +<TD><P>Get the contents of a file (the bytes stored in it)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node FileGetContentsQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileContents</TD> +<TD><a href="#FileGetContentsResponse.FileContents">FileGetContentsResponse.FileContents</a></TD> +<TD><P>the file ID and contents (a state proof can be generated for this)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file whose contents are being returned</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes contained in the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileGetInfo</TD> +<TD><a href="#FileGetInfoResponse">FileGetInfoResponse</a></TD> +<TD><P>Get information about a file, such as its expiration date</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node FileGetInfoQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileInfo</TD> +<TD><a href="#FileGetInfoResponse.FileInfo">FileGetInfoResponse.FileInfo</a></TD> +<TD><P>The information about the file (a state proof can be generated for this)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file for which information is requested</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>size</TD> +<TD>int64</TD> +<TD><P>Number of bytes in contents</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The current time at which this account is set to expire</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>deleted</TD> +<TD>bool</TD> +<TD><P>True if deleted but not yet expired</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>One of these keys must sign in order to modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionGetReceipt</TD> +<TD><a href="#TransactionGetReceiptResponse">TransactionGetReceiptResponse</a></TD> +<TD><P>Get a receipt for a transaction (lasts 180 seconds)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node TransactionGetReceiptQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. No State proof is available for this response </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The receipt, indicating it reached consensus (and whether it succeeded or failed) or is currently unknown (because it hasn't reached consensus yet, or the transaction has expired already), and including the ID of any new account/file/instance created by that transaction.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionGetRecord</TD> +<TD><a href="#TransactionGetRecordResponse">TransactionGetRecordResponse</a></TD> +<TD><P>Get a record for a transaction (lasts 1 hour)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node TransactionGetRecordQuery </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionRecord</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a></TD> +<TD><P>The requested record</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +</TR> + +<TR> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionGetFastRecord</TD> +<TD><a href="#TransactionGetFastRecordResponse">TransactionGetFastRecordResponse</a></TD> +<TD><P>Get a record for a transaction (lasts 180 seconds)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionRecord</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a></TD> +<TD><P>The requested transaction records</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>status</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> +</TR> + +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> +</TR> + +<TR> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> +</TR> + +<TR> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> +</TR> + +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> +</TR> + +<TR> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> +</TR> + +<TR> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> +</TR> + +<TR> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>consensusGetTopicInfo</TD> +<TD><a href="#ConsensusGetTopicInfoResponse">ConsensusGetTopicInfoResponse</a></TD> +<TD><P>Parameters of and state of a consensus topic..</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Retrieve the parameters of and state of a consensus topic.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P> Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicInfo</TD> +<TD><a href="#ConsensusTopicInfo">ConsensusTopicInfo</a></TD> +<TD><P>Current state of the topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>runningHash</TD> +<TD>bytes</TD> +<TD><P> SHA-384 running hash <previousRunningHash, topicId, consensusTimestamp, sequenceNumber, message></P></TD> +</TR> + +<TR> +<TD>sequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Sequence number (starting at 1 for the first submitMessage) of messages on the topic.</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which submitMessage calls will no longer succeed on the topic<BR>and the topic will expire and after AUTORENEW_GRACE_PERIOD be automatically deleted.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for update/delete of the topic. Null if there is no key.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for ConsensusService.submitMessage. Null if there is no key.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>Null if there is no autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ResponseCode.proto">ResponseCode.proto</H2> +<a href="#title">Top</a> +</div> +<H3 id="ResponseCodeEnum"><span class="BigBadge">Enum</span>ResponseCodeEnum</H3> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="ResponseHeader.proto">ResponseHeader.proto</H2> +<a href="#title">Top</a> +</div> +<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +</TR> + +<TR> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TR> + +<TR> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +</TR> + +<TR> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> +</TR> + +<TR> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TR> + +<TR> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> +</TR> + +<TR> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> +</TR> + +<TR> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> +</TR> + +<TR> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="enum-table"> +<thead> +<TR> +<TD>Enum Name</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> +</TR> + +<TR> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +</TR> + +<TR> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="SmartContractService.proto">SmartContractService.proto</H2> +<a href="#title">Top</a> +</div> +<P> The request and responses for different smart contract services. </P> +<H3 id="SmartContractService"><span class="BigBadge">Service</span>SmartContractService</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>RPC</TD> +<TD>Request</TD> +<TD>Response</TD> +<TD>Comments</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>createContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<TR> +<TD>updateContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<TR> +<TD>contractCallMethod </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<TR> +<TD>getContractInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the contract information by submitting the query. The grpc server returns the Response<TD><P></P></TD> +</TR> + +<TR> +<TD>contractCallLocalMethod </TD><TD>Query</TD><TD>Response</TD>Calls a smart contract by submitting the query. The grpc server returns the Response<TD><P></P></TD> +</TR> + +<TR> +<TD>ContractGetBytecode </TD><TD>Query</TD><TD>Response</TD>Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response<TD><P></P></TD> +</TR> + +<TR> +<TD>getBySolidityID </TD><TD>Query</TD><TD>Response</TD>Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response<TD><P></P></TD> +</TR> + +<TR> +<TD>getTxRecordByContractID </TD><TD>Query</TD><TD>Response</TD>Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response<TD><P></P></TD> +</TR> + +<TR> +<TD>deleteContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<TR> +<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<TR> +<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="SystemDelete.proto">SystemDelete.proto</H2> +<a href="#title">Top</a> +</div> +<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>SystemDeleteTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="SystemUndelete.proto">SystemUndelete.proto</H2> +<a href="#title">Top</a> +</div> +<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>SystemUndeleteTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="Timestamp.proto">Timestamp.proto</H2> +<a href="#title">Top</a> +</div> +<P> 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) </P> +<H3 id="Timestamp"><span class="BigBadge">Message</span>Timestamp</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +<H3 id="TimestampSeconds"><span class="BigBadge">Message</span>TimestampSeconds</H3> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="Transaction.proto">Transaction.proto</H2> +<a href="#title">Top</a> +</div> +<P> 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.<BR>The SignatureList field is deprecated and succeeded by SignatureMap.</P> +<H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> <TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> -<TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -202919,132 +257340,153 @@ <H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> -</TR> - -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="SmartContractService.proto">SmartContractService.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="SmartContractService"><span class="BigBadge">Service</span>SmartContractService</H3> +<TD> </TD> +<TD colspan=2> <P></P> <table class="field-table"> <thead> <TR> -<TD>RPC</TD> -<TD>Request</TD> -<TD>Response</TD> -<TD>Comments</TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>createContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> -<TD>updateContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>contractCallMethod </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>getContractInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the contract information by submitting the query. The grpc server returns the Response</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>contractCallLocalMethod </TD><TD>Query</TD><TD>Response</TD><TD><P>Calls a smart contract by submitting the query. The grpc server returns the Response</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>ContractGetBytecode </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>getBySolidityID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>getTxRecordByContractID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response</P></TD> +</TD> </TR> - <TR> -<TD>deleteContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> -<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> -<div class="file-heading"> -<H2 id="SystemDelete.proto">SystemDelete.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>SystemDeleteTransactionBody</H3> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -203055,14 +257497,15 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -203073,15 +257516,15 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -203104,9 +257547,9 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -203115,15 +257558,55 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -203146,9 +257629,9 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -203156,47 +257639,16 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="SystemUndelete.proto">SystemUndelete.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>SystemUndeleteTransactionBody</H3> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -203207,7 +257659,7 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -203225,15 +257677,15 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -203256,9 +257708,9 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -203267,15 +257719,33 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -203286,39 +257756,62 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="Timestamp.proto">Timestamp.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="Timestamp"><span class="BigBadge">Message</span>Timestamp</H3> -<P> 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) </P> +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -203329,22 +257822,39 @@ <H3 id="Timestamp"><span class="BigBadge">Message</span>Timestamp</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> -<H3 id="TimestampSeconds"><span class="BigBadge">Message</span>TimestampSeconds</H3> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +</TD> +</TR> +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -203355,31 +257865,36 @@ <H3 id="TimestampSeconds"><span class="BigBadge">Message</span>TimestampSeconds< </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -<div class="file-heading"> -<H2 id="Transaction.proto">Transaction.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> -<P> 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.</P> -<table class="field-table"> -<thead> +</TD> +</TR> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>bodyData</TD> +<TD>sendRecordThresholdField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -203397,15 +257912,28 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> <table class="field-table"> <thead> <TR> @@ -203416,15 +257944,29 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -203435,15 +257977,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>transactionValidStart</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -203471,15 +258024,14 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -203490,43 +258042,53 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -203549,9 +258111,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -203560,21 +258122,45 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -203587,7 +258173,13 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -203596,26 +258188,34 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -203626,15 +258226,14 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> <table class="field-table"> <thead> <TR> @@ -203647,7 +258246,7 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -203687,38 +258286,105 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -203729,15 +258395,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -203759,27 +258436,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -203974,30 +258645,108 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>gas</TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>initialBalance</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -204020,9 +258769,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -204031,15 +258780,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -204052,7 +258801,13 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -204061,21 +258816,34 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -204086,26 +258854,33 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -204127,21 +258902,45 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -204152,7 +258951,84 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>key</TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -204170,9 +259046,51 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> @@ -204211,34 +259129,18 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> +<tbody> +</TABLE> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -204249,21 +259151,31 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -204274,37 +259186,33 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -204315,33 +259223,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -204350,28 +259246,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> @@ -204408,18 +259285,25 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -204430,15 +259314,27 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>nanos</TD> +<TD>startMin</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -204446,16 +259342,41 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> +<TR> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + <TR> <TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -204653,15 +259574,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -204672,38 +259593,14 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -204714,26 +259611,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -204756,9 +259642,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -204767,26 +259653,33 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> + <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -204797,15 +259690,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -204816,37 +259715,37 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -204857,15 +259756,39 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -204876,21 +259799,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -204899,15 +259810,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -204930,9 +259841,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -204942,40 +259853,19 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -204986,15 +259876,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -205017,9 +259907,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -205028,21 +259918,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -205053,15 +259943,32 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -205183,18 +260090,20 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -205205,8 +260114,6 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -205216,15 +260123,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -205235,14 +260142,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> -<tbody> -</TABLE> - +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -205252,38 +260160,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>key</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -205481,15 +260372,39 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -205528,34 +260443,40 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -205566,26 +260487,43 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -205596,26 +260534,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -205637,21 +260564,53 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -205662,14 +260621,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -205680,15 +260646,20 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -205699,56 +260670,39 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -205759,34 +260713,32 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -205797,6 +260749,8 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -205806,15 +260760,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -205825,22 +260779,72 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> -</TD> +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> </TR> + <tbody> </TABLE> <tbody> @@ -205853,16 +260857,35 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="TransactionBody.proto">TransactionBody.proto</H2> +<a href="#title">Top</a> +</div> +<P> A single transaction. All transaction types are possible here. </P> +<H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -205873,15 +260896,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -205892,21 +260915,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -205915,9 +260932,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>deleteAccountID</TD> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> @@ -205962,28 +260979,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> +<TD>nodeAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> @@ -206023,26 +261021,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -206053,15 +261046,37 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -206072,15 +261087,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -206091,15 +261106,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -206122,9 +261137,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -206133,36 +261148,38 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -206173,15 +261190,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -206204,9 +261221,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -206215,15 +261232,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -206420,10 +261437,22 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -206463,20 +261492,51 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -206487,28 +261547,62 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -206519,29 +261613,33 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -206552,9 +261650,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -206563,15 +261673,33 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -206582,31 +261710,62 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -206617,17 +261776,22 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> <tbody> @@ -206636,15 +261800,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -206655,15 +261830,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -206686,20 +261861,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -206708,34 +261872,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -206763,34 +261908,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -206912,18 +262038,20 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -206934,8 +262062,6 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -206945,21 +262071,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -206970,26 +262090,39 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -207011,21 +262144,27 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -207036,33 +262175,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -207085,9 +262217,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -207096,33 +262228,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -207133,21 +262258,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -207158,37 +262277,37 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -207199,63 +262318,57 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -207278,9 +262391,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -207290,19 +262403,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -207313,15 +262428,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -207332,38 +262447,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -207374,15 +262466,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -207390,10 +262488,16 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> +<TR> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> @@ -207418,7 +262522,7 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -207573,26 +262677,55 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -207603,14 +262736,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -207621,15 +262755,14 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -207640,32 +262773,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -207704,18 +262814,34 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -207726,31 +262852,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -207761,33 +262877,37 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -207798,38 +262918,45 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -207852,9 +262979,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -207862,23 +262989,34 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> </TR> + <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -207889,27 +263027,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> -</TR> - -<TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -207918,27 +263038,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> @@ -207955,15 +263057,26 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -207985,53 +263098,21 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -208042,21 +263123,14 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> +<TD>key</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> -<TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -208067,20 +263141,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -208091,39 +263160,56 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -208134,32 +263220,34 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -208170,8 +263258,6 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -208181,34 +263267,15 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -208219,53 +263286,22 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </thead> <tbody> <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> -</TR> - -<TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> -</TR> - -<TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> -</TR> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +</TD> </TR> - <tbody> </TABLE> <tbody> @@ -208278,34 +263314,16 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> </TD> </TR> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="TransactionBody.proto">TransactionBody.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H3> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -208316,15 +263334,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -208335,15 +263353,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -208352,9 +263376,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>accountID</TD> +<TD>deleteAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> @@ -208399,9 +263423,28 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToDeleteFrom</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> @@ -208441,21 +263484,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -208466,37 +263514,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -208507,15 +263533,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -208526,15 +263552,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -208557,9 +263583,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -208567,39 +263593,37 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> - <TR> <TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -208610,15 +263634,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -208641,9 +263665,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -208652,15 +263676,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -208857,22 +263881,10 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> -</TR> - <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -208912,15 +263924,20 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -208931,32 +263948,61 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <tbody> </TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -208967,9 +264013,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -208978,15 +264024,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -208997,15 +264043,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -209014,15 +264060,14 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>receiverSigRequiredField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -209033,14 +264078,34 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -209051,15 +264116,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -209082,9 +264147,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -209093,33 +264158,45 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -209130,15 +264207,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -209163,29 +264251,104 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -209195,10 +264358,16 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> </thead> <tbody> +<TR> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + <TR> <TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> @@ -209210,6 +264379,18 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <tbody> </TABLE> +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -209219,46 +264400,27 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -209271,19 +264433,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -209292,15 +264442,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -209311,15 +264461,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -209328,15 +264478,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -209531,18 +264681,42 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -209565,26 +264739,31 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -209595,20 +264774,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> @@ -209648,9 +264816,34 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -209659,15 +264852,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -209678,15 +264871,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -209697,30 +264890,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>obtainers</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -209738,15 +264908,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -209769,9 +264939,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -209780,15 +264950,33 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -209799,23 +264987,42 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> @@ -209823,21 +265030,30 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <tbody> </TABLE> + +</TD> +</TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -209848,15 +265064,14 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> <table class="field-table"> <thead> <TR> @@ -209867,15 +265082,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -209898,9 +265113,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -209909,21 +265124,59 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -209934,15 +265187,31 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -209953,7 +265222,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>key</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -209971,15 +265240,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -210002,9 +265271,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -210013,33 +265282,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> -</TR> - -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> - -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -210050,62 +265301,45 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -210116,36 +265350,44 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> -</TD> +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -210156,15 +265398,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>key</TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -210362,177 +265610,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> - -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -210729,40 +265815,16 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - <TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -210773,21 +265835,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -210796,9 +265846,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>deleteAccountID</TD> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> @@ -210843,15 +265893,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -210862,15 +265912,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -210893,9 +265943,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>accountNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -210904,26 +265954,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -210934,15 +265979,32 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -210953,15 +266015,14 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -210972,15 +266033,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -211003,9 +266064,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -211014,36 +266075,33 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -211054,15 +266112,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -211073,38 +266137,80 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>key</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -211302,9 +266408,39 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> @@ -211341,23 +266477,42 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -211368,28 +266523,43 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> <TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -211400,29 +266570,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> - -<tbody> -</TABLE> -<TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -211433,9 +266589,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -211444,15 +266612,47 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="TransactionGetFastRecord.proto">TransactionGetFastRecord.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). </P> +<H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>TransactionGetFastRecordQuery</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -211463,24 +266663,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>receiverSigRequiredField</TD> +<TD>bodyData</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -211498,34 +266700,53 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - -<tbody> -</TABLE> +</thead> <tbody> -</TABLE> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -211536,15 +266757,32 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -211567,9 +266805,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -211577,27 +266815,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -211608,34 +266840,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -211644,15 +266863,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +</TR> + +<TR> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -211663,15 +266888,37 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +</TR> + +<TR> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> <table class="field-table"> <thead> <TR> @@ -211682,14 +266929,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -211702,7 +266950,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> @@ -211742,105 +266990,38 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> +<TD>functionParameters</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> -</TR> - -<TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -211851,26 +267032,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -211892,21 +267062,27 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TD><P>The realm number (nonnegative)</P></TD> </TR> +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -212101,42 +267277,30 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -212159,31 +267323,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -212194,15 +267353,32 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -212215,19 +267391,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -212236,15 +267400,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -212255,15 +267419,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -212272,34 +267436,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -212421,31 +267566,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -212453,27 +267593,21 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -212484,33 +267618,50 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -212521,32 +267672,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> @@ -212585,18 +267713,16 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<tbody> -</TABLE> <TR> <TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -212612,26 +267738,27 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -212642,7 +267769,7 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -212660,15 +267787,15 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -212691,9 +267818,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -212702,15 +267829,33 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -212721,45 +267866,62 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -212770,56 +267932,75 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> -</TR> - -<TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> @@ -212836,15 +268017,26 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </thead> <tbody> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -212867,9 +268059,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TR> <TR> -<TD>topicNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -212878,9 +268070,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> <TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> <tbody> @@ -212888,36 +268080,16 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H </TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -<div class="file-heading"> -<H2 id="TransactionGetFastRecord.proto">TransactionGetFastRecord.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>TransactionGetFastRecordQuery</H3> -<P> Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -212928,15 +268100,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -212947,33 +268119,37 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -</thead> + <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>obtainers</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> <table class="field-table"> <thead> <TR> @@ -212984,15 +268160,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -213003,34 +268179,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> +<TD>realmNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -213039,15 +268202,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>transferContractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -213070,9 +268233,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -213082,13 +268245,53 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> @@ -213128,21 +268331,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> </TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -213153,37 +268356,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> -</TR> - -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -213194,15 +268375,14 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> <table class="field-table"> <thead> <TR> @@ -213215,7 +268395,7 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -213255,38 +268435,33 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>functionParameters</TD> +<TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -213297,15 +268472,62 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>claimDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -213316,38 +268538,55 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -213544,22 +268783,16 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - <TR> <TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> <TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -213598,16 +268831,34 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + <TR> <TD>autoRenewPeriod</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -213628,22 +268879,16 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -213667,7 +268912,7 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -213703,13 +268948,13 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -213904,12 +269149,67 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -213918,15 +269218,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -213937,15 +269237,62 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -213968,9 +269315,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -213979,15 +269326,26 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -213998,15 +269356,78 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -214015,15 +269436,97 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>accountIDToUpdate</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -214263,15 +269766,20 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> <table class="field-table"> <thead> <TR> @@ -214282,26 +269790,28 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -214312,49 +269822,29 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> </TR> <tbody> </TABLE> - -</TD> -</TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214365,15 +269855,26 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214384,21 +269885,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -214407,7 +269902,7 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>obtainers</TD> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -214425,15 +269920,34 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214444,38 +269958,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -214498,9 +269989,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -214508,42 +269999,27 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes to append to the contents of the file</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214554,15 +270030,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214573,21 +270049,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -214595,16 +270065,10 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - <TR> <TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -214629,7 +270093,7 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -214784,15 +270248,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -214803,36 +270273,26 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -214843,15 +270303,32 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>key</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -215046,24 +270523,42 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -215086,9 +270581,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -215096,34 +270591,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TD> </TR> - <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215134,26 +270616,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -215166,7 +270637,19 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>shardNum</TD> <TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -215175,15 +270658,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215194,15 +270677,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -215211,15 +270694,34 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -215341,20 +270843,18 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -215365,6 +270865,8 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -215374,15 +270876,26 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215393,44 +270906,14 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> <table class="field-table"> <thead> <TR> @@ -215441,15 +270924,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -215472,9 +270955,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -215483,15 +270966,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -215514,9 +270997,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -215526,38 +271009,16 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> - -</TD> -</TR> -<TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> -</TR> - <TR> -<TD> </TD> -<TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -215568,21 +271029,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> @@ -215590,27 +271039,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215621,15 +271064,14 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -215640,15 +271082,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -215659,15 +271101,38 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -215690,20 +271155,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -215713,24 +271167,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215738,18 +271189,47 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TD>Type</TD> <TD>Description</TD> </TR> -</thead> -<tbody> +</thead> +<tbody> +<TR> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<TR> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +</TR> + +<TR> +<TD>endMin</TD> +<TD>int32</TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -215760,38 +271240,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>key</TD> +<TD>adminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -215989,15 +271452,52 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -216020,9 +271520,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -216031,20 +271531,33 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -216055,28 +271568,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -216087,29 +271593,37 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> + +</TD> +</TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -216120,26 +271634,39 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216152,13 +271679,7 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -216167,14 +271688,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>receiverSigRequiredField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -216185,34 +271707,43 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216223,15 +271754,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -216254,20 +271785,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -216276,34 +271796,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216331,34 +271838,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -216480,18 +271968,20 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -216502,8 +271992,6 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -216513,21 +272001,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -216538,62 +272020,39 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -216788,23 +272247,18 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216815,15 +272269,26 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -216846,9 +272311,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -216862,15 +272327,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216881,15 +272346,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -216912,26 +272377,31 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD>consensusSubmitMessage</TD> +<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -216942,15 +272412,40 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to submit message to.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -216959,34 +272454,41 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> +<TD>message</TD> +<TD>bytes</TD> +<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>bodyBytes</TD> +<TD>bytes</TD> +<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> </TR> -</thead> + <tbody> +</TABLE> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -216997,14 +272499,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>key</TD> -<TD>oneof</TD> +<TD>deprecated</TD> +<TD>option</TD> <TD><P></P></TD> </TR> +<TR> +<TD>sigs</TD> +<TD><a href="#Signature">Signature</a> (repeated)</TD> +<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -217015,15 +272524,20 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>signature</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -217034,56 +272548,39 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>ed25519</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>ed25519 signature bytes</P></TD> </TR> <TR> <TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> +<TD><P>RSA-3072 signature bytes</P></TD> </TR> <TR> <TD>ECDSA_384</TD> <TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +<TD><P>ECDSA p-384 signature bytes</P></TD> </TR> <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>thresholdSignature</TD> +<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -217094,15 +272591,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> +<TD>deprecated</TD> +<TD>option</TD> +<TD><P></P></TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>sigs</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> </TR> <TR> @@ -217117,9 +272614,9 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>signatureList</TD> +<TD><a href="#SignatureList">SignatureList</a></TD> +<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> </TR> <TR> @@ -217141,26 +272638,34 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +<TD>sigMap</TD> +<TD><a href="#SignatureMap">SignatureMap</a></TD> +<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>sigPair</TD> +<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> +<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -217171,7 +272676,13 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>id</TD> +<TD>pubKeyPrefix</TD> +<TD>bytes</TD> +<TD><P>First few bytes of the public key</P></TD> +</TR> + +<TR> +<TD>signature</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -217189,57 +272700,104 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contract</TD> +<TD>bytes</TD> +<TD><P>smart contract virtual signature (always length zero)</P></TD> +</TR> + +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 signature</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 signature</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA p-384 signature</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>responseType</TD> +<TD><a href="#ResponseType">ResponseType</a></TD> +<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>ANSWER_ONLY</TD> +<TD><P>Response returns answer</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>ANSWER_STATE_PROOF</TD> +<TD><P>Response returns both answer and state proof</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>COST_ANSWER</TD> +<TD><P>Response returns the cost of answer</P></TD> +</TR> + +<TR> +<TD>COST_ANSWER_STATE_PROOF</TD> +<TD><P>Response returns the total cost of answer and state proof</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction for which the record is requested.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -217250,21 +272808,34 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>realmNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -217272,18 +272843,16 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -217294,9 +272863,21 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -217309,16 +272890,11 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>TransactionGetFastRecordResponse</H3> +<P> Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. </P> <table class="field-table"> <thead> <TR> @@ -217329,14 +272905,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P></P> <table class="field-table"> <thead> <TR> @@ -217347,505 +272924,623 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>nodeTransactionPrecheckCode</TD> +<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> +<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> -<table class="field-table"> +<P></P> +<table class="enum-table"> <thead> <TR> -<TD>Field</TD> -<TD>Type</TD> +<TD>Enum Name</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>OK</TD> +<TD><P>The transaction passed the precheck validations.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION</TD> +<TD><P>For any error not handled by specific error codes listed below.</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_NOT_FOUND</TD> +<TD><P>Payer account does not exist.</P></TD> +</TR> + +<TR> +<TD>INVALID_NODE_ACCOUNT</TD> +<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_EXPIRED</TD> +<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_START</TD> +<TD><P>Transaction start time is greater than current consensus time</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_DURATION</TD> +<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_SIGNATURE</TD> +<TD><P>The transaction signature is not valid</P></TD> +</TR> + +<TR> +<TD>MEMO_TOO_LONG</TD> +<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_TX_FEE</TD> +<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_PAYER_BALANCE</TD> +<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> +</TR> + +<TR> +<TD>DUPLICATE_TRANSACTION</TD> +<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +</TR> + +<TR> +<TD>BUSY</TD> +<TD><P>If API is throttled out</P></TD> +</TR> + +<TR> +<TD>NOT_SUPPORTED</TD> +<TD><P>The API is not currently supported</P></TD> +</TR> + +<TR> +<TD>INVALID_FILE_ID</TD> +<TD><P>The file id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_ACCOUNT_ID</TD> +<TD><P>The account id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_CONTRACT_ID</TD> +<TD><P>The contract id is invalid or does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_TRANSACTION_ID</TD> +<TD><P>Transaction id is not valid</P></TD> +</TR> + +<TR> +<TD>RECEIPT_NOT_FOUND</TD> +<TD><P>Receipt for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>RECORD_NOT_FOUND</TD> +<TD><P>Record for given transaction id does not exist</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ID</TD> +<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +</TR> + +<TR> +<TD>UNKNOWN</TD> +<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +</TR> + +<TR> +<TD>SUCCESS</TD> +<TD><P>The transaction succeeded</P></TD> +</TR> + +<TR> +<TD>FAIL_INVALID</TD> +<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> +</TR> + +<TR> +<TD>FAIL_FEE</TD> +<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TR> + +<TR> +<TD>FAIL_BALANCE</TD> +<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TR> + +<TR> +<TD>KEY_REQUIRED</TD> +<TD><P>Key not provided in the transaction body</P></TD> +</TR> + +<TR> +<TD>BAD_ENCODING</TD> +<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> +<TD><P>When the account balance is not sufficient for the transfer</P></TD> +</TR> + +<TR> +<TD>INVALID_SOLIDITY_ADDRESS</TD> +<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_GAS</TD> +<TD><P>Not enough gas was supplied to execute transaction</P></TD> +</TR> + +<TR> +<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>contract byte code size is over the limit</P></TD> +</TR> + +<TR> +<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> +<TD><P>local execution (query) is requested for a function which changes state</P></TD> +</TR> + +<TR> +<TD>CONTRACT_REVERT_EXECUTED</TD> +<TD><P>Contract REVERT OPCODE executed</P></TD> +</TR> + +<TR> +<TD>CONTRACT_EXECUTION_EXCEPTION</TD> +<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> +<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> +</TR> + +<TR> +<TD>MISSING_QUERY_HEADER</TD> +<TD><P>Header is missing in Query request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_UPDATE_FAILED</TD> +<TD><P>The update of the account failed</P></TD> +</TR> + +<TR> +<TD>INVALID_KEY_ENCODING</TD> +<TD><P>Provided key encoding was not supported by the system</P></TD> +</TR> + +<TR> +<TD>NULL_SOLIDITY_ADDRESS</TD> +<TD><P>null solidity address</P></TD> +</TR> + +<TR> +<TD>CONTRACT_UPDATE_FAILED</TD> +<TD><P>update of the contract failed</P></TD> +</TR> + +<TR> +<TD>INVALID_QUERY_HEADER</TD> +<TD><P>the query header is invalid</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_SUBMITTED</TD> +<TD><P>Invalid fee submitted</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_SIGNATURE</TD> +<TD><P>Payer signature is invalid</P></TD> +</TR> + +<TR> +<TD>KEY_NOT_PROVIDED</TD> +<TD><P>The keys were not provided in the request.</P></TD> +</TR> + +<TR> +<TD>INVALID_EXPIRATION_TIME</TD> +<TD><P>Expiration time provided in the transaction was invalid.</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>NO_WACL_KEY</TD> +<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> </TR> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>FILE_CONTENT_EMPTY</TD> +<TD><P>The contents of file are provided as empty.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>INVALID_ACCOUNT_AMOUNTS</TD> +<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_TRANSACTION_BODY</TD> +<TD><P>Transaction body provided is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_TRANSACTION_BODY</TD> +<TD><P>Invalid transaction body provided</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> +<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> +<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>EMPTY_CLAIM_BODY</TD> +<TD><P>the claim body is empty</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>EMPTY_CLAIM_HASH</TD> +<TD><P>the hash for the claim is empty</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>EMPTY_CLAIM_KEYS</TD> +<TD><P>the key list is empty</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>INVALID_CLAIM_HASH_SIZE</TD> +<TD><P>the size of the claim hash is not 48 bytes</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD>EMPTY_QUERY_BODY</TD> +<TD><P>the query body is empty</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>EMPTY_CLAIM_QUERY</TD> +<TD><P>the crypto claim query is empty</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>CLAIM_NOT_FOUND</TD> +<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> </TR> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> +<TD><P>the account id passed has not yet been created.</P></TD> </TR> + <TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>CLAIM_ALREADY_EXISTS</TD> +<TD><P>the claim hash already exists</P></TD> </TR> <TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> </TR> <TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> </TR> <TR> -<TD>consensusSubmitMessage</TD> -<TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> -<TD><P></P></TD> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P></P> -<table class="field-table"> -<thead> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>Topic to submit message to.</P></TD> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> -<table class="field-table"> -<thead> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> </TR> <TR> -<TD>topicNum</TD> -<TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> -</TD> +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> </TR> + <TR> -<TD>message</TD> -<TD>bytes</TD> -<TD><P>Message to be submitted. Max size of the Transaction (including signatures) is 4kB.</P></TD> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> -</TD> +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> </TR> + <TR> -<TD>bodyBytes</TD> -<TD>bytes</TD> -<TD><P>TransactionBody serialized into bytes , which needs to be signed</P></TD> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field</P></TD> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> -<table class="field-table"> -<thead> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#Signature">Signature</a> (repeated)</TD> -<TD><P>each signature corresponds to a Key in the KeyList</P></TD> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature bytes</P></TD> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature bytes</P></TD> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature bytes</P></TD> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> </TR> <TR> -<TD>thresholdSignature</TD> -<TD><a href="#ThresholdSignature">ThresholdSignature</a></TD> -<TD><P>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.</P></TD> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>deprecated</TD> -<TD>option</TD> -<TD><P></P></TD> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> </TR> <TR> -<TD>sigs</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null</P></TD> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> </TR> + <TR> -<TD>signatureList</TD> -<TD><a href="#SignatureList">SignatureList</a></TD> -<TD><P>A list of M signatures, each corresponding to a Key in a KeyList of the same length.</P></TD> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> </TR> + <TR> -<TD>sigMap</TD> -<TD><a href="#SignatureMap">SignatureMap</a></TD> -<TD><P>The signatures on the body with the new format, to authorize the transaction</P></TD> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> -<table class="field-table"> -<thead> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>sigPair</TD> -<TD><a href="#SignaturePair">SignaturePair</a> (repeated)</TD> -<TD><P>Each signature pair corresponds to a unique Key required to sign the transaction.</P></TD> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> -<table class="field-table"> -<thead> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>pubKeyPrefix</TD> -<TD>bytes</TD> -<TD><P>First few bytes of the public key</P></TD> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> </TR> <TR> -<TD>signature</TD> -<TD>oneof</TD> +<TD>INVALID_ADMIN_KEY</TD> <TD><P></P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>contract</TD> -<TD>bytes</TD> -<TD><P>smart contract virtual signature (always length zero)</P></TD> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> </TR> <TR> -<TD>ed25519</TD> -<TD>bytes</TD> -<TD><P>ed25519 signature</P></TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> </TR> <TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 signature</P></TD> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> </TR> <TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA p-384 signature</P></TD> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> @@ -217854,13 +273549,13 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran <TR> <TD>responseType</TD> <TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response, asking for cost, state proof, both, or neither</P></TD> +<TD><P>The requested response is repeated back here, for convenience</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -217894,59 +273589,16 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction for which the record is requested.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>cost</TD> +<TD>uint64</TD> +<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>stateProof</TD> +<TD>bytes</TD> +<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> </TR> <tbody> @@ -217955,57 +273607,15 @@ <H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>transactionRecord</TD> +<TD><a href="#TransactionRecord">TransactionRecord</a></TD> +<TD><P>The requested transaction records</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -<H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>TransactionGetFastRecordResponse</H3> -<P> Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -218016,15 +273626,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#ResponseHeader">ResponseHeader</a></TD> -<TD><P>Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither</P></TD> +<TD>receipt</TD> +<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> +<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -218035,9 +273645,9 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>nodeTransactionPrecheckCode</TD> +<TD>status</TD> <TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>Result of fee transaction precheck, saying it passed, or why it failed</P></TD> +<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> </TR> <TR> @@ -218633,23 +274243,461 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionHash</TD> +<TD>bytes</TD> +<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> +</TR> + +<TR> +<TD>consensusTimestamp</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>The ID of the transaction this record represents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -218658,75 +274706,73 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>responseType</TD> -<TD><a href="#ResponseType">ResponseType</a></TD> -<TD><P>The requested response is repeated back here, for convenience</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> -<table class="enum-table"> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>ANSWER_ONLY</TD> -<TD><P>Response returns answer</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ANSWER_STATE_PROOF</TD> -<TD><P>Response returns both answer and state proof</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>COST_ANSWER</TD> -<TD><P>Response returns the cost of answer</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>COST_ANSWER_STATE_PROOF</TD> -<TD><P>Response returns the total cost of answer and state proof</P></TD> -</TR> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cost</TD> -<TD>uint64</TD> -<TD><P>The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee)</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> </TR> <TR> -<TD>stateProof</TD> -<TD>bytes</TD> -<TD><P>The state proof for this information (if a state proof was requested, and is available)</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transactionRecord</TD> -<TD><a href="#TransactionRecord">TransactionRecord</a></TD> -<TD><P>The requested transaction records</P></TD> +<TD>body</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> <table class="field-table"> <thead> <TR> @@ -218737,15 +274783,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>receipt</TD> -<TD><a href="#TransactionReceipt">TransactionReceipt</a></TD> -<TD><P>The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created.</P></TD> +<TD>contractCallResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -218756,638 +274802,770 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>status</TD> -<TD><a href="#ResponseCodeEnum">ResponseCodeEnum</a></TD> -<TD><P>whether the transaction succeeded or failed (or is unknown)</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P></P> -<table class="enum-table"> +<P> The ID for a smart contract instance </P> +<table class="field-table"> <thead> <TR> -<TD>Enum Name</TD> +<TD>Field</TD> +<TD>Type</TD> <TD>Description</TD> </TR> </thead> <tbody> <TR> -<TD>OK</TD> -<TD><P>The transaction passed the precheck validations.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION</TD> -<TD><P>For any error not handled by specific error codes listed below.</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PAYER_ACCOUNT_NOT_FOUND</TD> -<TD><P>Payer account does not exist.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_NODE_ACCOUNT</TD> -<TD><P>Node Account provided does not match the node account of the node the transaction was submitted to.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_EXPIRED</TD> -<TD><P>Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time.</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_TRANSACTION_START</TD> -<TD><P>Transaction start time is greater than current consensus time</P></TD> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_DURATION</TD> -<TD><P>valid transaction duration is a positive non zero number that does not exceed 120 seconds</P></TD> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> </TR> <TR> -<TD>INVALID_SIGNATURE</TD> -<TD><P>The transaction signature is not valid</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> </TR> <TR> -<TD>MEMO_TOO_LONG</TD> -<TD><P>Transaction memo size exceeded 100 bytes</P></TD> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> </TR> <TR> -<TD>INSUFFICIENT_TX_FEE</TD> -<TD><P>The fee provided in the transaction is insufficient for this type of transaction</P></TD> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> <TR> -<TD>INSUFFICIENT_PAYER_BALANCE</TD> -<TD><P>The payer account has insufficient cryptocurrency to pay the transaction fee</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>DUPLICATE_TRANSACTION</TD> -<TD><P>This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period)</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>BUSY</TD> -<TD><P>If API is throttled out</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> -<TD>NOT_SUPPORTED</TD> -<TD><P>The API is not currently supported</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_FILE_ID</TD> -<TD><P>The file id is invalid or does not exist</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ACCOUNT_ID</TD> -<TD><P>The account id is invalid or does not exist</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_CONTRACT_ID</TD> -<TD><P>The contract id is invalid or does not exist</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_TRANSACTION_ID</TD> -<TD><P>Transaction id is not valid</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>RECEIPT_NOT_FOUND</TD> -<TD><P>Receipt for given transaction id does not exist</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>RECORD_NOT_FOUND</TD> -<TD><P>Record for given transaction id does not exist</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SOLIDITY_ID</TD> -<TD><P>The solidity id is invalid or entity with this solidity id does not exist</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>UNKNOWN</TD> -<TD><P>Transaction hasn't yet reached consensus, or has already expired</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> -<TD>SUCCESS</TD> -<TD><P>The transaction succeeded</P></TD> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> -<TR> -<TD>FAIL_INVALID</TD> -<TD><P>There was a system error and the transaction failed because of invalid request parameters.</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_FEE</TD> -<TD><P>There was a system error while performing fee calculation, reserved for future.</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>FAIL_BALANCE</TD> -<TD><P>There was a system error while performing balance checks, reserved for future.</P></TD> +</TD> </TR> - <TR> -<TD>KEY_REQUIRED</TD> -<TD><P>Key not provided in the transaction body</P></TD> +<TD>contractCreateResult</TD> +<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> +<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> </TR> <TR> -<TD>BAD_ENCODING</TD> -<TD><P>Unsupported algorithm/encoding used for keys in the transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<table class="field-table"> +<thead> <TR> -<TD>INSUFFICIENT_ACCOUNT_BALANCE</TD> -<TD><P>When the account balance is not sufficient for the transfer</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SOLIDITY_ADDRESS</TD> -<TD><P>During an update transaction when the system is not able to find the Users Solidity address</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the smart contract instance whose function was called</P></TD> </TR> <TR> -<TD>INSUFFICIENT_GAS</TD> -<TD><P>Not enough gas was supplied to execute transaction</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>contract byte code size is over the limit</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>LOCAL_CALL_MODIFICATION_EXCEPTION</TD> -<TD><P>local execution (query) is requested for a function which changes state</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_REVERT_EXECUTED</TD> -<TD><P>Contract REVERT OPCODE executed</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_EXECUTION_EXCEPTION</TD> -<TD><P>For any contract execution related error not handled by specific error codes listed above.</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_RECEIVING_NODE_ACCOUNT</TD> -<TD><P>In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>MISSING_QUERY_HEADER</TD> -<TD><P>Header is missing in Query request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_UPDATE_FAILED</TD> -<TD><P>The update of the account failed</P></TD> +<TD>contractCallResult</TD> +<TD>bytes</TD> +<TD><P>the result returned by the function</P></TD> </TR> <TR> -<TD>INVALID_KEY_ENCODING</TD> -<TD><P>Provided key encoding was not supported by the system</P></TD> +<TD>errorMessage</TD> +<TD>string</TD> +<TD><P>message In case there was an error during smart contract execution</P></TD> </TR> <TR> -<TD>NULL_SOLIDITY_ADDRESS</TD> -<TD><P>null solidity address</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for record</P></TD> </TR> <TR> -<TD>CONTRACT_UPDATE_FAILED</TD> -<TD><P>update of the contract failed</P></TD> +<TD>gasUsed</TD> +<TD>uint64</TD> +<TD><P>units of gas used to execute contract</P></TD> </TR> <TR> -<TD>INVALID_QUERY_HEADER</TD> -<TD><P>the query header is invalid</P></TD> +<TD>logInfo</TD> +<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> +<TD><P>the log info for events returned by the function</P></TD> </TR> <TR> -<TD>INVALID_FEE_SUBMITTED</TD> -<TD><P>Invalid fee submitted</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_PAYER_SIGNATURE</TD> -<TD><P>Payer signature is invalid</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_NOT_PROVIDED</TD> -<TD><P>The keys were not provided in the request.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>address of a contract that emitted the event</P></TD> </TR> <TR> -<TD>INVALID_EXPIRATION_TIME</TD> -<TD><P>Expiration time provided in the transaction was invalid.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> <TR> -<TD>NO_WACL_KEY</TD> -<TD><P>WriteAccess Control Keys are not provided for the file</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_CONTENT_EMPTY</TD> -<TD><P>The contents of file are provided as empty.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_ACCOUNT_AMOUNTS</TD> -<TD><P>The crypto transfer credit and debit do not sum equal to 0</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>EMPTY_TRANSACTION_BODY</TD> -<TD><P>Transaction body provided is empty</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_TRANSACTION_BODY</TD> -<TD><P>Invalid transaction body provided</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_SIGNATURE_TYPE_MISMATCHING_KEY</TD> -<TD><P>the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature)</P></TD> +</TD> </TR> - <TR> -<TD>INVALID_SIGNATURE_COUNT_MISMATCHING_KEY</TD> -<TD><P>the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures.</P></TD> +<TD>bloom</TD> +<TD>bytes</TD> +<TD><P>bloom filter for a particular log</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_BODY</TD> -<TD><P>the claim body is empty</P></TD> +<TD>topic</TD> +<TD>bytes (repeated)</TD> +<TD><P>topics of a particular event</P></TD> </TR> <TR> -<TD>EMPTY_CLAIM_HASH</TD> -<TD><P>the hash for the claim is empty</P></TD> +<TD>data</TD> +<TD>bytes</TD> +<TD><P>event data</P></TD> </TR> -<TR> -<TD>EMPTY_CLAIM_KEYS</TD> -<TD><P>the key list is empty</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_CLAIM_HASH_SIZE</TD> -<TD><P>the size of the claim hash is not 48 bytes</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>EMPTY_QUERY_BODY</TD> -<TD><P>the query body is empty</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <TR> -<TD>EMPTY_CLAIM_QUERY</TD> -<TD><P>the crypto claim query is empty</P></TD> +<TD>transferList</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> </TR> <TR> -<TD>CLAIM_NOT_FOUND</TD> -<TD><P>the crypto claim doesn't exists in the file system. It expired or was never persisted.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<table class="field-table"> +<thead> <TR> -<TD>ACCOUNT_ID_DOES_NOT_EXIST</TD> -<TD><P>the account id passed has not yet been created.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CLAIM_ALREADY_EXISTS</TD> -<TD><P>the claim hash already exists</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TD> </TR> - <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> </TR> -<TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TD> </TR> +<tbody> +</TABLE> +<div class="file-heading"> +<H2 id="TransactionGetReceipt.proto">TransactionGetReceipt.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response</P> +<H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>TransactionGetReceiptQuery</H3> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> </TR> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> </TR> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> </TR> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<tbody> +</TABLE> + +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> +<TD>data</TD> +<TD>oneof</TD> <TD><P></P></TD> </TR> <TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -219410,9 +275588,32 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> +</TR> + +<TR> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +</TR> + +<TR> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> <tbody> @@ -219421,9 +275622,28 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>fileID</TD> <TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> @@ -219463,9 +275683,46 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -219505,34 +275762,33 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Two sets of exchange rate </P> -<table class="field-table"> -<thead> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -219543,27 +275799,21 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -219574,11 +275824,17 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -219590,15 +275846,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -219609,42 +275865,17 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +Self Reference +</TD> </TR> - <tbody> </TABLE> @@ -219652,24 +275883,33 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TR> <tbody> </TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -219692,26 +275932,9 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TR> <TR> -<TD>topicNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -219720,21 +275943,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>transactionHash</TD> -<TD>bytes</TD> -<TD><P>The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID)</P></TD> -</TR> - -<TR> -<TD>consensusTimestamp</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The consensus timestamp (or null if didn't reach consensus yet)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -219747,13 +275964,7 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -219762,34 +275973,21 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>The ID of the transaction this record represents</P></TD> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -219800,15 +275998,9 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -219817,15 +276009,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -219847,43 +276039,21 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo that was submitted as part of the transaction (max 100 bytes)</P></TD> -</TR> - -<TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The actual transaction fee charged, not the original transactionFee value from TransactionBody</P></TD> -</TR> - -<TR> -<TD>body</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -219894,15 +276064,14 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>contractCallResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> <table class="field-table"> <thead> <TR> @@ -219915,7 +276084,7 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -219955,39 +276124,33 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>contractCallResult</TD> +<TD>ed25519</TD> <TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> -<TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>bloom</TD> +<TD>RSA_3072</TD> <TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -219998,15 +276161,21 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -220017,46 +276186,17 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> -</TR> - -<TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - -<TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> -</TR> - <tbody> </TABLE> @@ -220068,15 +276208,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>contractCreateResult</TD> -<TD><a href="#ContractFunctionResult">ContractFunctionResult</a></TD> -<TD><P>Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -220087,81 +276227,50 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the smart contract instance whose function was called</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractCallResult</TD> -<TD>bytes</TD> -<TD><P>the result returned by the function</P></TD> -</TR> - -<TR> -<TD>errorMessage</TD> +<TD>memo</TD> <TD>string</TD> -<TD><P>message In case there was an error during smart contract execution</P></TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> </TR> -<TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for record</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>gasUsed</TD> -<TD>uint64</TD> -<TD><P>units of gas used to execute contract</P></TD> +</TD> </TR> - <TR> -<TD>logInfo</TD> -<TD><a href="#ContractLoginfo">ContractLoginfo</a> (repeated)</TD> -<TD><P>the log info for events returned by the function</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -220174,7 +276283,7 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>address of a contract that emitted the event</P></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> </TR> <TR> @@ -220214,45 +276323,51 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>bloom</TD> -<TD>bytes</TD> -<TD><P>bloom filter for a particular log</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> -<TD>topic</TD> -<TD>bytes (repeated)</TD> -<TD><P>topics of a particular event</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>data</TD> -<TD>bytes</TD> -<TD><P>event data</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> -</TD> +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> -<tbody> -</TABLE> <TR> -<TD>transferList</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers.</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -220263,15 +276378,14 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> <table class="field-table"> <thead> <TR> @@ -220282,15 +276396,15 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </thead> <tbody> <TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -220313,9 +276427,9 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -220324,54 +276438,33 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T </TD> </TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -</TD> +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> -<tbody> -</TABLE> -<div class="file-heading"> -<H2 id="TransactionGetReceipt.proto">TransactionGetReceipt.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>TransactionGetReceiptQuery</H3> -<P> Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response</P> -<table class="field-table"> -<thead> <TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -220382,33 +276475,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -220419,34 +276500,37 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -220457,45 +276541,33 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> +</TABLE> -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -220534,21 +276606,46 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -220571,9 +276668,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -220582,21 +276679,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -220607,30 +276709,49 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> + <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>data</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -220648,15 +276769,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -220667,9 +276788,32 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>contractID</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -220708,39 +276852,42 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -220751,15 +276898,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -220782,9 +276929,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -220793,15 +276940,40 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -220920,25 +277092,6 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TD><P>List of all the keys that can sign</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -220948,11 +277101,6 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> @@ -220961,34 +277109,10 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TD><P>A list of Keys of the Key type.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -220998,70 +277122,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> +<TD>claimDuration</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -221082,52 +277157,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -221138,32 +277187,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -221318,69 +277350,64 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -221391,15 +277418,56 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -221410,21 +277478,39 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>contractNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -221433,15 +277519,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -221452,15 +277538,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <tbody> @@ -221469,15 +277555,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -221672,12 +277758,36 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -221717,45 +277827,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -221778,9 +277858,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -221788,27 +277868,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -221819,15 +277893,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -221850,9 +277924,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -221861,14 +277935,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -221879,15 +277965,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -221898,38 +277984,34 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -221952,9 +278034,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -221962,42 +278044,37 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> + +</TD> +</TR> <tbody> </TABLE> </TD> </TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +</TD> </TR> -</thead> -<tbody> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222008,9 +278085,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>accountIDToUpdate</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> @@ -222050,40 +278127,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -222202,6 +278254,25 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -222211,6 +278282,11 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -222219,6 +278295,25 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -222227,26 +278322,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -222257,9 +278352,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -222267,26 +278374,86 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> + <tbody> </TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222297,15 +278464,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222316,7 +278494,24 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>key</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -222334,15 +278529,53 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -222365,9 +278598,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -222376,33 +278609,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222413,21 +278639,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222438,31 +278658,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> +<TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -222487,37 +278702,44 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -222540,9 +278762,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -222551,33 +278773,33 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -222588,26 +278810,68 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222631,7 +278895,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -222673,7 +278937,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -222876,34 +279140,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -222914,38 +279159,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -222968,9 +279190,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -222984,15 +279206,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223003,15 +279225,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -223034,20 +279256,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -223056,72 +279267,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223132,78 +279286,32 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -223214,38 +279322,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -223367,20 +279452,18 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -223391,6 +279474,8 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -223400,15 +279485,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223419,39 +279515,33 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -223474,9 +279564,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -223485,20 +279575,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -223509,61 +279594,40 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> +</TABLE> -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TD> </TR> - <tbody> </TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -223576,24 +279640,29 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223604,24 +279673,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>receiverSigRequiredField</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -223639,34 +279691,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -223677,15 +279710,38 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -223708,9 +279764,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -223718,27 +279774,23 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223749,34 +279801,27 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>nanos</TD> +<TD>endMin</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -223785,15 +279830,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -223804,15 +279849,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -223934,18 +279985,20 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -223956,8 +280009,6 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -223967,21 +280018,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -223992,62 +280037,39 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -224242,23 +280264,18 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -224269,15 +280286,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -224300,9 +280328,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -224316,15 +280344,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -224335,15 +280363,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -224366,9 +280394,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -224376,16 +280404,22 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -224413,34 +280447,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -224559,6 +280574,25 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -224568,6 +280602,11 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -224579,14 +280618,26 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference </TD> </TR> <tbody> @@ -224594,27 +280645,23 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -224625,7 +280672,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>id</TD> +<TD>key</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -224643,15 +280690,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -224674,9 +280721,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -224685,15 +280732,33 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -224704,40 +280769,21 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> -<tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -224748,11 +280794,17 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -224764,15 +280816,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -224783,33 +280835,39 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -224820,21 +280878,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -224843,15 +280889,15 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -224874,9 +280920,9 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -224886,21 +280932,19 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -224911,27 +280955,40 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -224939,24 +280996,11 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +</TD> </TR> - <TR> <TD>consensusSubmitMessage</TD> <TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> @@ -225053,7 +281097,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -225078,7 +281122,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -225145,7 +281189,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -225211,7 +281255,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -225230,7 +281274,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -225314,7 +281358,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -225381,7 +281425,7 @@ <H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>Transac <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -225478,7 +281522,7 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -226098,12 +282142,12 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -226120,7 +282164,7 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -226180,7 +282224,7 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -226519,304 +282563,1312 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>INVALID_FILE_WACL</TD> -<TD><P>File WACL keys are invalid</P></TD> +<TD>INVALID_FILE_WACL</TD> +<TD><P>File WACL keys are invalid</P></TD> +</TR> + +<TR> +<TD>SERIALIZATION_FAILED</TD> +<TD><P>Serialization failure</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_OVERSIZE</TD> +<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>TRANSACTION_TOO_MANY_LAYERS</TD> +<TD><P>The Transaction has more than 50 levels</P></TD> +</TR> + +<TR> +<TD>CONTRACT_DELETED</TD> +<TD><P>Contract is marked as deleted</P></TD> +</TR> + +<TR> +<TD>PLATFORM_NOT_ACTIVE</TD> +<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +</TR> + +<TR> +<TD>KEY_PREFIX_MISMATCH</TD> +<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +</TR> + +<TR> +<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> +<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +</TR> + +<TR> +<TD>INVALID_RENEWAL_PERIOD</TD> +<TD><P>auto renewal period is not a positive number of seconds</P></TD> +</TR> + +<TR> +<TD>INVALID_PAYER_ACCOUNT_ID</TD> +<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_DELETED</TD> +<TD><P>the account has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>FILE_DELETED</TD> +<TD><P>the file has been marked as deleted</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> +<TD><P>same accounts repeated in the transfer account list</P></TD> +</TR> + +<TR> +<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> +<TD><P>attempting to set negative balance value for crypto account</P></TD> +</TR> + +<TR> +<TD>OBTAINER_REQUIRED</TD> +<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +</TR> + +<TR> +<TD>OBTAINER_SAME_CONTRACT_ID</TD> +<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +</TR> + +<TR> +<TD>OBTAINER_DOES_NOT_EXIST</TD> +<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +</TR> + +<TR> +<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> +<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +</TR> + +<TR> +<TD>FILE_SYSTEM_EXCEPTION</TD> +<TD><P>Unexpected exception thrown by file system functions</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> +<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +</TR> + +<TR> +<TD>ERROR_DECODING_BYTESTRING</TD> +<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +</TR> + +<TR> +<TD>CONTRACT_FILE_EMPTY</TD> +<TD><P>File to create a smart contract was of length zero</P></TD> +</TR> + +<TR> +<TD>CONTRACT_BYTECODE_EMPTY</TD> +<TD><P>Bytecode for smart contract is of length zero</P></TD> +</TR> + +<TR> +<TD>INVALID_INITIAL_BALANCE</TD> +<TD><P>Attempt to set negative initial balance</P></TD> +</TR> + +<TR> +<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative receive record threshold</P></TD> +</TR> + +<TR> +<TD>INVALID_SEND_RECORD_THRESHOLD</TD> +<TD><P>attempt to set negative send record threshold</P></TD> +</TR> + +<TR> +<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> +<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +</TR> + +<TR> +<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> +<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +</TR> + +<TR> +<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> +<TD><P>FreezeTransactionBody is invalid</P></TD> +</TR> + +<TR> +<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> +<TD><P>FreezeTransactionBody does not exist</P></TD> +</TR> + +<TR> +<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +</TR> + +<TR> +<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> +<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +</TR> + +<TR> +<TD>NOT_SPECIAL_ACCOUNT</TD> +<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_GAS</TD> +<TD><P>Negative gas was offered in smart contract call</P></TD> +</TR> + +<TR> +<TD>CONTRACT_NEGATIVE_VALUE</TD> +<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +</TR> + +<TR> +<TD>INVALID_FEE_FILE</TD> +<TD><P>Failed to update fee file</P></TD> +</TR> + +<TR> +<TD>INVALID_EXCHANGE_RATE_FILE</TD> +<TD><P>Failed to update exchange rate file</P></TD> +</TR> + +<TR> +<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> +<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +</TR> + +<TR> +<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> +<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +</TR> + +<TR> +<TD>AUTHORIZATION_FAILED</TD> +<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_INVALID</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> +<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +</TR> + +<TR> +<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> +<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +</TR> + +<TR> +<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> +<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +</TR> + +<TR> +<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> +<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> +<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +</TR> + +<TR> +<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> +<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +</TR> + +<TR> +<TD>MAX_GAS_LIMIT_EXCEEDED</TD> +<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +</TR> + +<TR> +<TD>MAX_FILE_SIZE_EXCEEDED</TD> +<TD><P>File size exceeded the currently allowable limit</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_ID</TD> +<TD><P>The Topic ID specified is not in the system.</P></TD> +</TR> + +<TR> +<TD>INVALID_ADMIN_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>INVALID_SUBMIT_KEY</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>UNAUTHORIZED</TD> +<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TR> + +<TR> +<TD>INVALID_TOPIC_MESSAGE</TD> +<TD><P>A ConsensusService message is empty.</P></TD> +</TR> + +<TR> +<TD>INVALID_AUTORENEW_ACCOUNT</TD> +<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +</TR> + +<TR> +<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> +</TR> + +<TR> +<TD>TOPIC_EXPIRED</TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID, if a new account was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID, if a new file was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>exchangeRate</TD> +<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> +<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Two sets of exchange rate </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>currentRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>nextRate</TD> +<TD><a href="#ExchangeRate">ExchangeRate</a></TD> +<TD><P>Next rate exchange of Hbar to cents</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>hbarEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote habar equivalent to cent</P></TD> +</TR> + +<TR> +<TD>centEquiv</TD> +<TD>int32</TD> +<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>expired time in seconds for this exchange rate</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>TopicID of a newly created consensus service topic</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>topicSequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<TR> +<TD>topicRunningHash</TD> +<TD>bytes</TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +<div class="file-heading"> +<H2 id="TransactionGetRecord.proto">TransactionGetRecord.proto</H2> +<a href="#title">Top</a> +</div> +<P> Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. </P> +<H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>TransactionGetRecordQuery</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>payment</TD> +<TD><a href="#Transaction">Transaction</a></TD> +<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>bodyData</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>body</TD> +<TD><a href="#TransactionBody">TransactionBody</a></TD> +<TD><P>the body of the transaction, which needs to be signed</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionID</TD> +<TD><a href="#TransactionID">TransactionID</a></TD> +<TD><P>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</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transactionValidStart</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that paid for this transaction</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>SERIALIZATION_FAILED</TD> -<TD><P>Serialization failure</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> -<TR> -<TD>TRANSACTION_OVERSIZE</TD> -<TD><P>The size of the Transaction is greater than transactionMaxBytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>TRANSACTION_TOO_MANY_LAYERS</TD> -<TD><P>The Transaction has more than 50 levels</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>CONTRACT_DELETED</TD> -<TD><P>Contract is marked as deleted</P></TD> +<TD>nodeAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account of the node that submits the client's transaction to the network</P></TD> </TR> <TR> -<TD>PLATFORM_NOT_ACTIVE</TD> -<TD><P>the platform node is either disconnected or lagging behind.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for an a cryptocurrency account </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>KEY_PREFIX_MISMATCH</TD> -<TD><P>one public key matches more than one prefixes on the signature map</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>PLATFORM_TRANSACTION_NOT_CREATED</TD> -<TD><P>transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_RENEWAL_PERIOD</TD> -<TD><P>auto renewal period is not a positive number of seconds</P></TD> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_PAYER_ACCOUNT_ID</TD> -<TD><P>the response code when a smart contract id is passed for a crypto API request</P></TD> +<TD>transactionFee</TD> +<TD>uint64</TD> +<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> </TR> <TR> -<TD>ACCOUNT_DELETED</TD> -<TD><P>the account has been marked as deleted</P></TD> +<TD>transactionValidDuration</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> </TR> <TR> -<TD>FILE_DELETED</TD> -<TD><P>the file has been marked as deleted</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS</TD> -<TD><P>same accounts repeated in the transfer account list</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>SETTING_NEGATIVE_ACCOUNT_BALANCE</TD> -<TD><P>attempting to set negative balance value for crypto account</P></TD> +<TD>generateRecord</TD> +<TD>bool</TD> +<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> </TR> <TR> -<TD>OBTAINER_REQUIRED</TD> -<TD><P>when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> </TR> <TR> -<TD>OBTAINER_SAME_CONTRACT_ID</TD> -<TD><P>when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted</P></TD> +<TD>data</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>OBTAINER_DOES_NOT_EXIST</TD> -<TD><P>transferAccountId or transferContractId specified for contract delete does not exist</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MODIFYING_IMMUTABLE_CONTRACT</TD> -<TD><P>attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key)</P></TD> +<TD>contractCall</TD> +<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> +<TD><P>Contains the call a function of a contract instance</P></TD> </TR> <TR> -<TD>FILE_SYSTEM_EXCEPTION</TD> -<TD><P>Unexpected exception thrown by file system functions</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_DURATION_NOT_IN_RANGE</TD> -<TD><P>the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION]</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>the contract instance to call, in the format used in transactions</P></TD> </TR> <TR> -<TD>ERROR_DECODING_BYTESTRING</TD> -<TD><P>Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>CONTRACT_FILE_EMPTY</TD> -<TD><P>File to create a smart contract was of length zero</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_BYTECODE_EMPTY</TD> -<TD><P>Bytecode for smart contract is of length zero</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>INVALID_INITIAL_BALANCE</TD> -<TD><P>Attempt to set negative initial balance</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>INVALID_RECEIVE_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative receive record threshold</P></TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>the maximum amount of gas to use for the call</P></TD> </TR> <TR> -<TD>INVALID_SEND_RECORD_THRESHOLD</TD> -<TD><P>attempt to set negative send record threshold</P></TD> +<TD>amount</TD> +<TD>int64</TD> +<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> </TR> <TR> -<TD>ACCOUNT_IS_NOT_GENESIS_ACCOUNT</TD> -<TD><P>Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account</P></TD> +<TD>functionParameters</TD> +<TD>bytes</TD> +<TD><P>which function to call, and the parameters to pass to the function</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>PAYER_ACCOUNT_UNAUTHORIZED</TD> -<TD><P>The fee payer account doesn't have permission to submit such Transaction</P></TD> +<TD>contractCreateInstance</TD> +<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> +<TD><P>Contains the create data a contract instance</P></TD> </TR> <TR> -<TD>INVALID_FREEZE_TRANSACTION_BODY</TD> -<TD><P>FreezeTransactionBody is invalid</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FREEZE_TRANSACTION_BODY_NOT_FOUND</TD> -<TD><P>FreezeTransactionBody does not exist</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> -<TD>TRANSFER_LIST_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Exceeded the number of accounts (both from and to) allowed for crypto transfer list</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>RESULT_SIZE_LIMIT_EXCEEDED</TD> -<TD><P>Smart contract result size greater than specified maxResultSize</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>NOT_SPECIAL_ACCOUNT</TD> -<TD><P>The payer account is not a special account(account 0.0.55)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>CONTRACT_NEGATIVE_GAS</TD> -<TD><P>Negative gas was offered in smart contract call</P></TD> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>CONTRACT_NEGATIVE_VALUE</TD> -<TD><P>Negative value / initial balance was specified in a smart contract call / create</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> </TR> <TR> -<TD>INVALID_FEE_FILE</TD> -<TD><P>Failed to update fee file</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_EXCHANGE_RATE_FILE</TD> -<TD><P>Failed to update exchange rate file</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>INSUFFICIENT_LOCAL_CALL_GAS</TD> -<TD><P>Payment tendered for contract local call cannot cover both the fee and the gas</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>ENTITY_NOT_ALLOWED_TO_DELETE</TD> -<TD><P>Entities with Entity ID below 1000 are not allowed to be deleted</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> -<TD>AUTHORIZATION_FAILED</TD> -<TD><P>Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112).</P></TD> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>FILE_UPLOADED_PROTO_INVALID</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK</TD> -<TD><P>Fee Schedule Proto uploaded but not valid (append or update is required)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>FEE_SCHEDULE_FILE_PART_UPLOADED</TD> -<TD><P>Fee Schedule Proto File Part uploaded</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED</TD> -<TD><P>The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>MAX_CONTRACT_STORAGE_EXCEEDED</TD> -<TD><P>Contract permanent storage exceeded the currently allowable limit</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT</TD> -<TD><P>Transfer Account should not be same as Account to be deleted</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>TOTAL_LEDGER_BALANCE_INVALID</TD> -<TD><P></P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> -<TD>EXPIRATION_REDUCTION_NOT_ALLOWED</TD> -<TD><P>The expiration date/time on a smart contract may not be reduced</P></TD> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>MAX_GAS_LIMIT_EXCEEDED</TD> -<TD><P>Gas exceeded currently allowable gas limit per transaction</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>MAX_FILE_SIZE_EXCEEDED</TD> -<TD><P>File size exceeded the currently allowable limit</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>INVALID_TOPIC_ID</TD> -<TD><P>The Topic ID specified is not in the system.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>INVALID_ADMIN_KEY</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>INVALID_SUBMIT_KEY</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> -<TR> -<TD>UNAUTHORIZED</TD> -<TD><P>An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey).</P></TD> +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>INVALID_TOPIC_MESSAGE</TD> -<TD><P>A ConsensusService message is empty.</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> -<TD>INVALID_AUTORENEW_ACCOUNT</TD> -<TD><P>The autoRenewAccount specified is not a valid, active account.</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>gas</TD> +<TD>int64</TD> +<TD><P>gas to run the constructor</P></TD> +</TR> + +<TR> +<TD>initialBalance</TD> +<TD>int64</TD> +<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> +</TR> + +<TR> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID, if a new account was created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -226856,15 +283908,15 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID, if a new file was created</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -226875,21 +283927,45 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>shardNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>constructorParameters</TD> +<TD>bytes</TD> +<TD><P>parameters to pass to the constructor</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>shard in which to create this</P></TD> </TR> <TR> -<TD>fileNum</TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -226898,15 +283974,15 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID, if a new smart contract instance was created</P></TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -226928,27 +284004,21 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <TD><P>The realm number (nonnegative)</P></TD> </TR> -<TR> -<TD>contractNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>exchangeRate</TD> -<TD><a href="#ExchangeRateSet">ExchangeRateSet</a></TD> -<TD><P>exchange rate set of Hbar to cents (USD)</P></TD> +<TD>newRealmAdminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Two sets of exchange rate </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -226959,15 +284029,14 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>currentRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Current rate of Exchange of Hbar to cents</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> <table class="field-table"> <thead> <TR> @@ -226978,27 +284047,15 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> -</TR> - -<TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> -</TR> - -<TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -227009,31 +284066,56 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> -</TD> +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>nextRate</TD> -<TD><a href="#ExchangeRate">ExchangeRate</a></TD> -<TD><P>Next rate exchange of Hbar to cents</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -227044,27 +284126,62 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>hbarEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote habar equivalent to cent</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> </TR> <TR> -<TD>centEquiv</TD> -<TD>int32</TD> -<TD><P>value which denote cents (USD) equivalent to Hbar}</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>expired time in seconds for this exchange rate</P></TD> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -227075,11 +284192,17 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -227087,24 +284210,51 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>topicID</TD> -<TD><a href="#TopicID">TopicID</a></TD> -<TD><P>TopicID of a newly created consensus service topic</P></TD> +<TD>contractUpdateInstance</TD> +<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> +<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Unique identifier for a topic (used by the consensus service) </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -227127,9 +284277,9 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TR> <TR> -<TD>topicNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -227138,15 +284288,34 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TD> </TR> <TR> -<TD>topicSequenceNumber</TD> -<TD>uint64</TD> -<TD><P></P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> </TR> <TR> -<TD>topicRunningHash</TD> -<TD>bytes</TD> -<TD><P></P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> <tbody> @@ -227154,15 +284323,16 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +</TR> -<div class="file-heading"> -<H2 id="TransactionGetRecord.proto">TransactionGetRecord.proto</H2> -<a href="#title">Top</a> -</div> -<H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>TransactionGetRecordQuery</H3> -<P> Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. </P> +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -227173,15 +284343,14 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>header</TD> -<TD><a href="#QueryHeader">QueryHeader</a></TD> -<TD><P>Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither).</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> <thead> <TR> @@ -227192,15 +284361,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>payment</TD> -<TD><a href="#Transaction">Transaction</a></TD> -<TD><P>A signed CryptoTransferTransaction to pay the node a fee for handling this query</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -227211,14 +284380,56 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>bodyData</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -227229,15 +284440,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>body</TD> -<TD><a href="#TransactionBody">TransactionBody</a></TD> -<TD><P>the body of the transaction, which needs to be signed</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A single transaction. All transaction types are possible here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -227248,34 +284465,37 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>transactionID</TD> -<TD><a href="#TransactionID">TransactionID</a></TD> -<TD><P>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</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidStart</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -227286,26 +284506,33 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +</TD> +</TR> +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>accountID</TD> +<TD>proxyAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that paid for this transaction</P></TD> +<TD><P>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.</P></TD> </TR> <TR> @@ -227344,21 +284571,46 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> <TR> -<TD>nodeAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account of the node that submits the client's transaction to the network</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -227381,9 +284633,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -227392,21 +284644,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>transactionFee</TD> -<TD>uint64</TD> -<TD><P>The maximum transaction fee the client is willing to pay, which is split between the network and the node</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>transactionValidDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration</P></TD> +<TD>contractDeleteInstance</TD> +<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> +<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -227417,30 +284674,49 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a smart contract instance </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> + <TR> -<TD>generateRecord</TD> -<TD>bool</TD> -<TD><P>Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>Any notes or descriptions that should be put into the record (max length 100)</P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>data</TD> +<TD>obtainers</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -227458,15 +284734,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>contractCall</TD> -<TD><a href="#ContractCallTransactionBody">ContractCallTransactionBody</a></TD> -<TD><P>Contains the call a function of a contract instance</P></TD> +<TD>transferAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -227477,9 +284753,32 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>contractID</TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>transferContractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>the contract instance to call, in the format used in transactions</P></TD> +<TD><P>The contract ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -227518,39 +284817,42 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>the maximum amount of gas to use for the call</P></TD> -</TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <TR> -<TD>amount</TD> -<TD>int64</TD> -<TD><P>number of tinybars sent (the function must be payable if this is nonzero)</P></TD> +<TD>cryptoAddClaim</TD> +<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> +<TD><P>Attach a new claim to an account</P></TD> </TR> <TR> -<TD>functionParameters</TD> -<TD>bytes</TD> -<TD><P>which function to call, and the parameters to pass to the function</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>contractCreateInstance</TD> -<TD><a href="#ContractCreateTransactionBody">ContractCreateTransactionBody</a></TD> -<TD><P>Contains the create data a contract instance</P></TD> +<TD>claim</TD> +<TD><a href="#Claim">Claim</a></TD> +<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -227561,15 +284863,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>the account to which the claim is attached</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -227592,9 +284894,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -227603,15 +284905,40 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>adminKey</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance.</P></TD> +<TD>hash</TD> +<TD>bytes</TD> +<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -227730,25 +285057,6 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TD><P>List of all the keys that can sign</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> @@ -227758,11 +285066,6 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> @@ -227771,34 +285074,10 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TD><P>A list of Keys of the Key type.</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> -</TR> - <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -227808,70 +285087,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>gas</TD> -<TD>int64</TD> -<TD><P>gas to run the constructor</P></TD> -</TR> - -<TR> -<TD>initialBalance</TD> -<TD>int64</TD> -<TD><P>initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract</P></TD> -</TR> - -<TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The ID for an a cryptocurrency account </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> +<TD>claimDuration</TD> <TD><a href="#Duration">Duration</a></TD> -<TD><P>the instance will charge its account every this many seconds to renew for this long</P></TD> +<TD><P>the duration for which the claim will remain valid</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -227892,52 +285122,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>constructorParameters</TD> -<TD>bytes</TD> -<TD><P>parameters to pass to the constructor</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>shard in which to create this</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>realm in which to create this (leave this null to create a new realm)</P></TD> +<TD>cryptoCreateAccount</TD> +<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> +<TD><P>Create a new cryptocurrency account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -227948,32 +285152,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>newRealmAdminKey</TD> +<TD>key</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>if realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -228171,45 +285358,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>the memo that was submitted as part of the contract (max 100 bytes)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>contractUpdateInstance</TD> -<TD><a href="#ContractUpdateTransactionBody">ContractUpdateTransactionBody</a></TD> -<TD><P>Contains contract modify info such as expiration date for a contract instance</P></TD> +<TD>initialBalance</TD> +<TD>uint64</TD> +<TD><P>The initial number of tinybars to put into the account</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to update (this can't be changed)</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -228232,9 +285395,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -228243,15 +285406,33 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>Extend the expiration of the instance and its account to this time (no effect if it already is this time or later)</P></TD> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> + +<TR> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +</TR> + +<TR> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -228264,13 +285445,37 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>shardID</TD> +<TD><a href="#ShardID">ShardID</a></TD> +<TD><P>The shard in which this account is created</P></TD> </TR> <TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>the shard number (nonnegative)</P></TD> </TR> <tbody> @@ -228279,15 +285484,51 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>adminKey</TD> +<TD>realmID</TD> +<TD><a href="#RealmID">RealmID</a></TD> +<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>newRealmAdminKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance.</P></TD> +<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -228482,12 +285723,36 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>proxyAccountID</TD> +<TD>cryptoDelete</TD> +<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> +<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>transferAccountID</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD><P>The account ID which will receive all remaining hbars</P></TD> </TR> <TR> @@ -228527,45 +285792,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The instance will charge its account every this many seconds to renew for this long</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways:</P></TD> +<TD>deleteAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID which should be deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -228588,9 +285823,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -228598,27 +285833,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>memo</TD> -<TD>string</TD> -<TD><P>The memo associated with the contract (max 100 bytes)</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>contractDeleteInstance</TD> -<TD><a href="#ContractDeleteTransactionBody">ContractDeleteTransactionBody</a></TD> -<TD><P>Delete contract and transfer remaining balance into specified account</P></TD> +<TD>cryptoDeleteClaim</TD> +<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> +<TD><P>Remove a claim from an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -228629,15 +285858,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The Contract ID instance to delete (this can't be changed)</P></TD> +<TD>accountIDToDeleteFrom</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The account ID that should have a claim deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -228660,9 +285889,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -228671,14 +285900,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>obtainers</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>hashToDelete</TD> +<TD>bytes</TD> +<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>cryptoTransfer</TD> +<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> +<TD><P>Transfer amount between accounts</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> 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 to do the withdrawal, 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. </P> <table class="field-table"> <thead> <TR> @@ -228689,15 +285930,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>transfers</TD> +<TD><a href="#TransferList">TransferList</a></TD> +<TD><P>Accounts and amounts to transfer</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> <table class="field-table"> <thead> <TR> @@ -228708,38 +285949,34 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>accountAmounts</TD> +<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> +<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<P></P> +<table class="field-table"> +<thead> <TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>transferContractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID which will receive all remaining hbars</P></TD> +<TD>accountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -228762,9 +285999,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -228772,42 +286009,37 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<tbody> -</TABLE> +<TR> +<TD>amount</TD> +<TD><a href="#sint64">sint64</a></TD> +<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> +</TR> + <tbody> </TABLE> </TD> </TR> -<TR> -<TD>cryptoAddClaim</TD> -<TD><a href="#CryptoAddClaimTransactionBody">CryptoAddClaimTransactionBody</a></TD> -<TD><P>Attach a new claim to an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>claim</TD> -<TD><a href="#Claim">Claim</a></TD> -<TD><P>A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it</P></TD> +<TD>cryptoUpdateAccount</TD> +<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for an account</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -228818,9 +286050,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>accountID</TD> +<TD>accountIDToUpdate</TD> <TD><a href="#AccountID">AccountID</a></TD> -<TD><P>the account to which the claim is attached</P></TD> +<TD><P>The account ID which is being updated in this transaction</P></TD> </TR> <TR> @@ -228860,40 +286092,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>hash</TD> -<TD>bytes</TD> -<TD><P>48 byte SHA-384 hash (presumably of some kind of credential or certificate)</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys).</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>key</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>The new key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -229012,6 +286219,25 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TD><P>List of all the keys that can sign</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -229021,6 +286247,11 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> @@ -229029,6 +286260,25 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TD><P>A list of Keys of the Key type.</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> +</TR> + <TR> <TD> </TD> <TD colspan=2> @@ -229037,26 +286287,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> <TR> -<TD>claimDuration</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>the duration for which the claim will remain valid</P></TD> +<TD>proxyAccountID</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>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.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -229067,9 +286317,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> +<TD>shardNum</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>accountNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -229077,26 +286339,86 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> +<TR> +<TD>proxyFraction</TD> +<TD>int32</TD> +<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> +</TR> + +<TR> +<TD>sendRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> +<TR> +<TD>sendRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +</TR> -</TD> +<TR> +<TD>sendRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> </TR> + <tbody> </TABLE> +<TR> +<TD>receiveRecordThresholdField</TD> +<TD>oneof</TD> +<TD><P></P></TD> +</TR> -</TD> +<TR> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> +<tbody> <TR> -<TD>cryptoCreateAccount</TD> -<TD><a href="#CryptoCreateTransactionBody">CryptoCreateTransactionBody</a></TD> -<TD><P>Create a new cryptocurrency account</P></TD> +<TD>receiveRecordThreshold</TD> +<TD>uint64</TD> +<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<TR> +<TD>receiveRecordThresholdWrapper</TD> +<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> +<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TR> + +<tbody> +</TABLE> +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229107,15 +286429,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>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.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229126,7 +286459,24 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>key</TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> +</TR> + +<TR> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>receiverSigRequiredField</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -229144,15 +286494,53 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> +<TD>receiverSigRequired</TD> +<TD>bool</TD> +<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> +</TR> + +<TR> +<TD>receiverSigRequiredWrapper</TD> +<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> +<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +</TR> + +<tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>fileAppend</TD> +<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> +<TD><P>Add bytes to the end of the contents of a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -229175,9 +286563,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>contractNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -229186,33 +286574,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>ed25519</TD> +<TD>contents</TD> <TD>bytes</TD> -<TD><P>ed25519 public key bytes</P></TD> +<TD><P>The bytes to append to the contents of the file</P></TD> </TR> -<TR> -<TD>RSA_3072</TD> -<TD>bytes</TD> -<TD><P>RSA-3072 public key bytes</P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>ECDSA_384</TD> -<TD>bytes</TD> -<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TD> </TR> - <TR> -<TD>thresholdKey</TD> -<TD><a href="#ThresholdKey">ThresholdKey</a></TD> -<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +<TD>fileCreate</TD> +<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> +<TD><P>Create a new file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229223,21 +286604,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>threshold</TD> -<TD>uint32</TD> -<TD><P>A valid signature set must have at least this many signatures</P></TD> -</TR> - -<TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>List of all the keys that can sign</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229248,31 +286623,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -Self Reference -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>keyList</TD> +<TD>keys</TD> <TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> </TR> <TR> @@ -229297,37 +286667,44 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> +<TR> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> -<tbody> -</TABLE> -<tbody> -</TABLE> -</TD> -</TR> <TR> -<TD>initialBalance</TD> -<TD>uint64</TD> -<TD><P>The initial number of tinybars to put into the account</P></TD> +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> +<tbody> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -229350,9 +286727,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>accountNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -229361,33 +286738,33 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> </TR> <TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction</P></TD> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> </TR> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> </TR> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>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.</P></TD> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> 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. </P> <table class="field-table"> <thead> <TR> @@ -229398,26 +286775,68 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> </TR> +<tbody> +</TABLE> +<tbody> +</TABLE> +</TD> +</TR> <tbody> </TABLE> </TD> </TR> +<TR> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The bytes that are the contents of the file</P></TD> +</TR> + <TR> <TD>shardID</TD> <TD><a href="#ShardID">ShardID</a></TD> -<TD><P>The shard in which this account is created</P></TD> +<TD><P>Shard in which this file is created</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229441,7 +286860,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD>realmID</TD> <TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The realm in which this account is created (leave this null to create a new realm)</P></TD> +<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> </TR> <TR> @@ -229483,7 +286902,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -229686,34 +287105,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>cryptoDelete</TD> -<TD><a href="#CryptoDeleteTransactionBody">CryptoDeleteTransactionBody</a></TD> -<TD><P>Delete a cryptocurrency account (mark as deleted, and transfer hbars out)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transferAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which will receive all remaining hbars</P></TD> +<TD>fileDelete</TD> +<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> +<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229724,38 +287124,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>deleteAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which should be deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -229778,9 +287155,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -229794,15 +287171,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>cryptoDeleteClaim</TD> -<TD><a href="#CryptoDeleteClaimTransactionBody">CryptoDeleteClaimTransactionBody</a></TD> -<TD><P>Remove a claim from an account</P></TD> +<TD>fileUpdate</TD> +<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> +<TD><P>Modify information such as the expiration date for a file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229813,15 +287190,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>accountIDToDeleteFrom</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID that should have a claim deleted</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to update</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -229844,20 +287221,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>hashToDelete</TD> -<TD>bytes</TD> -<TD><P>The hash in the claim to delete (a SHA-384 hash, 48 bytes)</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -229866,72 +287232,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>cryptoTransfer</TD> -<TD><a href="#CryptoTransferTransactionBody">CryptoTransferTransactionBody</a></TD> -<TD><P>Transfer amount between accounts</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> 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 to do the withdrawal, 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>transfers</TD> -<TD><a href="#TransferList">TransferList</a></TD> -<TD><P>Accounts and amounts to transfer</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of accounts and amounts to transfer out of each account (negative) or into it (positive). </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountAmounts</TD> -<TD><a href="#AccountAmount">AccountAmount</a> (repeated)</TD> -<TD><P>Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The Account ID that sends or receives cryptocurrency</P></TD> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -229942,78 +287251,32 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>amount</TD> -<TD><a href="#sint64">sint64</a></TD> -<TD><P>The amount of tinybars that the account sends(negative) or receives(positive)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> +<TD>nanos</TD> +<TD>int32</TD> +<TD><P>Number of nanoseconds since the start of the last second</P></TD> </TR> -<tbody> -</TABLE> -</TD> -</TR> <tbody> </TABLE> </TD> </TR> <TR> -<TD>cryptoUpdateAccount</TD> -<TD><a href="#CryptoUpdateTransactionBody">CryptoUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for an account</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>accountIDToUpdate</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>The account ID which is being updated in this transaction</P></TD> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>The keys that can modify or delete the file</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -230024,38 +287287,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>accountNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>key</TD> -<TD><a href="#Key">Key</a></TD> -<TD><P>The new key</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -230177,20 +287417,18 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> @@ -230201,6 +287439,8 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <tbody> </TABLE> +<tbody> +</TABLE> </TD> </TR> @@ -230210,15 +287450,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>contents</TD> +<TD>bytes</TD> +<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>systemDelete</TD> +<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> +<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -230229,39 +287480,33 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>id</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> -</TR> -<tbody> -</TABLE> - -</TD> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>proxyAccountID</TD> -<TD><a href="#AccountID">AccountID</a></TD> -<TD><P>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.</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for an a cryptocurrency account </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -230284,9 +287529,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>accountNum</TD> +<TD>fileNum</TD> <TD>int64</TD> -<TD><P>A nonnegative account number unique within its realm</P></TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> </TR> <tbody> @@ -230295,20 +287540,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>proxyFraction</TD> -<TD>int32</TD> -<TD><P>[Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account</P></TD> -</TR> - -<TR> -<TD>sendRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -230319,61 +287559,40 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>sendRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>sendRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> -<tbody> -</TABLE> <TR> -<TD>receiveRecordThresholdField</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>contractNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> -<TR> -<TD> </TD> -<TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> <tbody> -<TR> -<TD>receiveRecordThreshold</TD> -<TD>uint64</TD> -<TD><P>[Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> -</TR> +</TABLE> -<TR> -<TD>receiveRecordThresholdWrapper</TD> -<TD><a href="#google.protobuf.UInt64Value">google.protobuf.UInt64Value</a></TD> -<TD><P>The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction.</P></TD> +</TD> </TR> - <tbody> </TABLE> <TR> -<TD>autoRenewPeriod</TD> -<TD><a href="#Duration">Duration</a></TD> -<TD><P>The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.</P></TD> +<TD>expirationTime</TD> +<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> +<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> <table class="field-table"> <thead> <TR> @@ -230386,24 +287605,29 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD>seconds</TD> <TD>int64</TD> -<TD><P>number of seconds</P></TD> +<TD><P>Number of complete seconds since the start of the epoch</P></TD> </TR> <tbody> </TABLE> +</TD> +</TR> +<tbody> +</TABLE> + </TD> </TR> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new expiration time to extend to (ignored if equal to or before the current one)</P></TD> +<TD>systemUndelete</TD> +<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> +<TD><P>To undelete an entity deleted by SystemDelete</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -230414,24 +287638,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> -</TR> - -<TR> -<TD>nanos</TD> -<TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>receiverSigRequiredField</TD> +<TD>id</TD> <TD>oneof</TD> <TD><P></P></TD> </TR> @@ -230449,34 +287656,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>receiverSigRequired</TD> -<TD>bool</TD> -<TD><P>[Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose.</P></TD> -</TR> - -<TR> -<TD>receiverSigRequiredWrapper</TD> -<TD><a href="#google.protobuf.BoolValue">google.protobuf.BoolValue</a></TD> -<TD><P>If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)</P></TD> -</TR> - -<tbody> -</TABLE> -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>fileAppend</TD> -<TD><a href="#FileAppendTransactionBody">FileAppendTransactionBody</a></TD> -<TD><P>Add bytes to the end of the contents of a file</P></TD> +<TD>fileID</TD> +<TD><a href="#FileID">FileID</a></TD> +<TD><P>The file ID to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<P> The ID for a file </P> <table class="field-table"> <thead> <TR> @@ -230487,15 +287675,38 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to which the bytes are appended to</P></TD> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> +</TR> + +<TR> +<TD>fileNum</TD> +<TD>int64</TD> +<TD><P>A nonnegative File number unique within its realm</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>contractID</TD> +<TD><a href="#ContractID">ContractID</a></TD> +<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for a smart contract instance </P> <table class="field-table"> <thead> <TR> @@ -230518,9 +287729,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>fileNum</TD> +<TD>contractNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative number unique within its realm</P></TD> </TR> <tbody> @@ -230528,27 +287739,23 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes to append to the contents of the file</P></TD> -</TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>fileCreate</TD> -<TD><a href="#FileCreateTransactionBody">FileCreateTransactionBody</a></TD> -<TD><P>Create a new file</P></TD> +<TD>freeze</TD> +<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> +<TD><P>Freeze the nodes</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -230559,34 +287766,27 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>expirationTime</TD> -<TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life)</P></TD> +<TD>startHour</TD> +<TD>int32</TD> +<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD> </TD> -<TD colspan=2> -<P> 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) </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +<TD>startMin</TD> +<TD>int32</TD> +<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> </TR> -</thead> -<tbody> + <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>endHour</TD> +<TD>int32</TD> +<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> </TR> <TR> -<TD>nanos</TD> +<TD>endMin</TD> <TD>int32</TD> -<TD><P>Number of nanoseconds since the start of the last second</P></TD> +<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> </TR> <tbody> @@ -230595,15 +287795,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>All these keys must sign to create or modify the file. Any one of them can sign to delete the file.</P></TD> +<TD>consensusCreateTopic</TD> +<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> A list of keys </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -230614,15 +287814,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -230744,18 +287950,20 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> @@ -230766,8 +287974,6 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> @@ -230777,21 +287983,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The bytes that are the contents of the file</P></TD> -</TR> - -<TR> -<TD>shardID</TD> -<TD><a href="#ShardID">ShardID</a></TD> -<TD><P>Shard in which this file is created</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -230802,62 +288002,39 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>the shard number (nonnegative)</P></TD> -</TR> - -<tbody> -</TABLE> - -</TD> -</TR> -<TR> -<TD>realmID</TD> -<TD><a href="#RealmID">RealmID</a></TD> -<TD><P>The Realm in which to the file is created (leave this null to create a new realm)</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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. </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> </TR> -</thead> <tbody> -<TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> +</TABLE> -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> +</TD> </TR> - +<tbody> +</TABLE> <tbody> </TABLE> </TD> </TR> <TR> -<TD>newRealmAdminKey</TD> +<TD>submitKey</TD> <TD><a href="#Key">Key</a></TD> -<TD><P>If realmID is null, then this the admin key for the new realm that will be created</P></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -231052,23 +288229,18 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <tbody> </TABLE> -</TD> -</TR> -<tbody> -</TABLE> - </TD> </TR> <TR> -<TD>fileDelete</TD> -<TD><a href="#FileDeleteTransactionBody">FileDeleteTransactionBody</a></TD> -<TD><P>Delete a file (remove contents and mark as deleted until it expires)</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -231079,15 +288251,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file to delete. It will be marked as deleted until it expires. Then it will disappear.</P></TD> +<TD>seconds</TD> +<TD>int64</TD> +<TD><P>number of seconds</P></TD> +</TR> + +<tbody> +</TABLE> + +</TD> +</TR> +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -231110,9 +288293,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>fileNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -231126,15 +288309,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>fileUpdate</TD> -<TD><a href="#FileUpdateTransactionBody">FileUpdateTransactionBody</a></TD> -<TD><P>Modify information such as the expiration date for a file</P></TD> +<TD>consensusUpdateTopic</TD> +<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -231145,15 +288328,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to update</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> Unique identifier for a topic (used by the consensus service) </P> <table class="field-table"> <thead> <TR> @@ -231176,9 +288359,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>fileNum</TD> +<TD>topicNum</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -231186,16 +288369,22 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + <TR> <TD>expirationTime</TD> <TD><a href="#Timestamp">Timestamp</a></TD> -<TD><P>The new time at which it should expire (ignored if not later than the current value)</P></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -231223,34 +288412,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>keys</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>The keys that can modify or delete the file</P></TD> -</TR> - -<TR> -<TD> </TD> -<TD colspan=2> -<P> A list of keys </P> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> -</TR> -</thead> -<tbody> -<TR> -<TD>keys</TD> -<TD><a href="#Key">Key</a> (repeated)</TD> -<TD><P>list of keys</P></TD> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -231372,31 +288542,26 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -Self Reference -</TD> +<P> A list of keys </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> -<TD>keyList</TD> -<TD><a href="#KeyList">KeyList</a></TD> -<TD><P>A list of Keys of the Key type.</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> Self Reference -</TD> -</TR> -<tbody> -</TABLE> -<tbody> -</TABLE> - </TD> </TR> <tbody> @@ -231404,27 +288569,21 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>contents</TD> -<TD>bytes</TD> -<TD><P>The new file contents. All the bytes in the old contents are discarded.</P></TD> -</TR> - <tbody> </TABLE> </TD> </TR> <TR> -<TD>systemDelete</TD> -<TD><a href="#SystemDeleteTransactionBody">SystemDeleteTransactionBody</a></TD> -<TD><P>Hedera multisig system deletes a file or smart contract</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -231435,33 +288594,39 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID of the file to delete, in the format used in transactions</P></TD> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -231472,32 +288637,27 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> +<TD>key</TD> +<TD>oneof</TD> +<TD><P></P></TD> </TR> <TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - +<TD> </TD> +<TD colspan=2> +<table class="field-table"> +<thead> <TR> -<TD>fileNum</TD> -<TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> </TR> - +</thead> <tbody> -</TABLE> - -</TD> -</TR> <TR> <TD>contractID</TD> <TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to delete, in the format used in transactions</P></TD> +<TD><P>smart contract instance that is authorized as if it had signed with a key</P></TD> </TR> <TR> @@ -231536,18 +288696,59 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> +<TR> +<TD>ed25519</TD> +<TD>bytes</TD> +<TD><P>ed25519 public key bytes</P></TD> +</TR> + +<TR> +<TD>RSA_3072</TD> +<TD>bytes</TD> +<TD><P>RSA-3072 public key bytes</P></TD> +</TR> + +<TR> +<TD>ECDSA_384</TD> +<TD>bytes</TD> +<TD><P>ECDSA with the p-384 curve public key bytes</P></TD> +</TR> + +<TR> +<TD>thresholdKey</TD> +<TD><a href="#ThresholdKey">ThresholdKey</a></TD> +<TD><P>a threshold N followed by a list of M keys, any N of which are required to form a valid signature</P></TD> +</TR> + +<TR> +<TD> </TD> +<TD colspan=2> +<P> 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. </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> <tbody> -</TABLE> <TR> -<TD>expirationTime</TD> -<TD><a href="#TimestampSeconds">TimestampSeconds</a></TD> -<TD><P>The timestamp in seconds at which the "deleted" file should truly be permanently deleted</P></TD> +<TD>threshold</TD> +<TD>uint32</TD> +<TD><P>A valid signature set must have at least this many signatures</P></TD> +</TR> + +<TR> +<TD>keys</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>List of all the keys that can sign</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> An exact date and time, with a resolution of one second (no nanoseconds). </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -231558,11 +288759,17 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>seconds</TD> -<TD>int64</TD> -<TD><P>Number of complete seconds since the start of the epoch</P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> +<TR> +<TD> </TD> +<TD colspan=2> +Self Reference +</TD> +</TR> <tbody> </TABLE> @@ -231574,15 +288781,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>systemUndelete</TD> -<TD><a href="#SystemUndeleteTransactionBody">SystemUndeleteTransactionBody</a></TD> -<TD><P>To undelete an entity deleted by SystemDelete</P></TD> +<TD>keyList</TD> +<TD><a href="#KeyList">KeyList</a></TD> +<TD><P>A list of Keys of the Key type.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<P> A list of keys </P> <table class="field-table"> <thead> <TR> @@ -231593,33 +288800,39 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>id</TD> -<TD>oneof</TD> -<TD><P></P></TD> +<TD>keys</TD> +<TD><a href="#Key">Key</a> (repeated)</TD> +<TD><P>list of keys</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<table class="field-table"> -<thead> -<TR> -<TD>Field</TD> -<TD>Type</TD> -<TD>Description</TD> +Self Reference +</TD> +</TR> +<tbody> +</TABLE> + +</TD> </TR> -</thead> <tbody> +</TABLE> +<tbody> +</TABLE> + +</TD> +</TR> <TR> -<TD>fileID</TD> -<TD><a href="#FileID">FileID</a></TD> -<TD><P>The file ID to undelete, in the format used in transactions</P></TD> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a file </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -231630,21 +288843,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>shardNum</TD> -<TD>int64</TD> -<TD><P>The shard number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>realmNum</TD> -<TD>int64</TD> -<TD><P>The realm number (nonnegative)</P></TD> -</TR> - -<TR> -<TD>fileNum</TD> +<TD>seconds</TD> <TD>int64</TD> -<TD><P>A nonnegative File number unique within its realm</P></TD> +<TD><P>number of seconds</P></TD> </TR> <tbody> @@ -231653,15 +288854,15 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> <TR> -<TD>contractID</TD> -<TD><a href="#ContractID">ContractID</a></TD> -<TD><P>The contract ID instance to undelete, in the format used in transactions</P></TD> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> The ID for a smart contract instance </P> +<P> The ID for an a cryptocurrency account </P> <table class="field-table"> <thead> <TR> @@ -231684,9 +288885,9 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <TR> -<TD>contractNum</TD> +<TD>accountNum</TD> <TD>int64</TD> -<TD><P>A nonnegative number unique within its realm</P></TD> +<TD><P>A nonnegative account number unique within its realm</P></TD> </TR> <tbody> @@ -231696,21 +288897,19 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TR> <tbody> </TABLE> -<tbody> -</TABLE> </TD> </TR> <TR> -<TD>freeze</TD> -<TD><a href="#FreezeTransactionBody">FreezeTransactionBody</a></TD> -<TD><P>Freeze the nodes</P></TD> +<TD>consensusDeleteTopic</TD> +<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> +<TD><P></P></TD> </TR> <TR> <TD> </TD> <TD colspan=2> -<P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -231721,27 +288920,40 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </thead> <tbody> <TR> -<TD>startHour</TD> -<TD>int32</TD> -<TD><P>The start hour (in UTC time), a value between 0 and 23</P></TD> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> </TR> <TR> -<TD>startMin</TD> -<TD>int32</TD> -<TD><P>The start minute (in UTC time), a value between 0 and 59</P></TD> +<TD> </TD> +<TD colspan=2> +<P> Unique identifier for a topic (used by the consensus service) </P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>shardNum</TD> +<TD>int64</TD> +<TD><P>The shard number (nonnegative)</P></TD> </TR> <TR> -<TD>endHour</TD> -<TD>int32</TD> -<TD><P>The end hour (in UTC time), a value between 0 and 23</P></TD> +<TD>realmNum</TD> +<TD>int64</TD> +<TD><P>The realm number (nonnegative)</P></TD> </TR> <TR> -<TD>endMin</TD> -<TD>int32</TD> -<TD><P>The end minute (in UTC time), a value between 0 and 59</P></TD> +<TD>topicNum</TD> +<TD>int64</TD> +<TD><P>Unique topic identifier within a realm (nonnegative).</P></TD> </TR> <tbody> @@ -231749,24 +288961,11 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact </TD> </TR> -<TR> -<TD>consensusCreateTopic</TD> -<TD><a href="#ConsensusCreateTopicTransactionBody">ConsensusCreateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> - -<TR> -<TD>consensusUpdateTopic</TD> -<TD><a href="#ConsensusUpdateTopicTransactionBody">ConsensusUpdateTopicTransactionBody</a></TD> -<TD><P></P></TD> -</TR> +<tbody> +</TABLE> -<TR> -<TD>consensusDeleteTopic</TD> -<TD><a href="#ConsensusDeleteTopicTransactionBody">ConsensusDeleteTopicTransactionBody</a></TD> -<TD><P></P></TD> +</TD> </TR> - <TR> <TD>consensusSubmitMessage</TD> <TD><a href="#ConsensusSubmitMessageTransactionBody">ConsensusSubmitMessageTransactionBody</a></TD> @@ -231863,7 +289062,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -231888,7 +289087,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -231955,7 +289154,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -232021,7 +289220,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -232040,7 +289239,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -232124,7 +289323,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -232191,7 +289390,7 @@ <H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>Transact <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -232288,7 +289487,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -232908,12 +290107,12 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -232930,7 +290129,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -232990,7 +290189,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> Response when the client sends the node TransactionGetRecordResponse </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -233009,7 +290208,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -233629,12 +290828,12 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -233796,7 +290995,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -233862,7 +291061,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -233969,13 +291168,13 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD>topicSequenceNumber</TD> <TD>uint64</TD> -<TD><P></P></TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <TR> <TD>topicRunningHash</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <tbody> @@ -233998,7 +291197,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -234053,7 +291252,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -234251,7 +291450,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -234425,7 +291624,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -234535,7 +291734,7 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -234615,8 +291814,9 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <H2 id="TransactionReceipt.proto">TransactionReceipt.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionReceipt</H3> <P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionReceipt</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -235236,12 +292436,12 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -235403,7 +292603,7 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -235469,7 +292669,7 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -235576,13 +292776,13 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <TR> <TD>topicSequenceNumber</TD> <TD>uint64</TD> -<TD><P></P></TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <TR> <TD>topicRunningHash</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <tbody> @@ -235592,8 +292792,9 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <H2 id="TransactionRecord.proto">TransactionRecord.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecord</H3> <P> Response when the client sends the node TransactionGetRecordResponse </P> +<H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecord</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -235612,7 +292813,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -236232,12 +293433,12 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -236399,7 +293600,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -236465,7 +293666,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> Values from these proto denotes habr and cents(USD) conversion </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -236572,13 +293773,13 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD>topicSequenceNumber</TD> <TD>uint64</TD> -<TD><P></P></TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <TR> <TD>topicRunningHash</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <tbody> @@ -236601,7 +293802,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -236656,7 +293857,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> 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) </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -236854,7 +294055,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -237028,7 +294229,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -237138,7 +294339,7 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <TR> <TD> </TD> <TD colspan=2> -<P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -237213,8 +294414,9 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <H2 id="TransactionResponse.proto">TransactionResponse.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionResponse"><span class="BigBadge">Message</span>TransactionResponse</H3> <P> When the client sends the node a transaction of any kind, the node replies with this, which simply says that the transaction passed the precheck (so the node will submit it to the network) or it failed (so it won't). If the fee offered was insufficient, this will also contain the amount of the required fee. To learn the consensus result, the client should later obtain a receipt (free), or can buy a more detailed record (not free). </P> +<H3 id="TransactionResponse"><span class="BigBadge">Message</span>TransactionResponse</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -237834,12 +295036,12 @@ <H3 id="TransactionResponse"><span class="BigBadge">Message</span>TransactionRes <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> diff --git a/docs/NestedDoc.md b/docs/NestedDoc.md deleted file mode 100644 index 7a430f7b..00000000 --- a/docs/NestedDoc.md +++ /dev/null @@ -1,2088 +0,0 @@ -# HAPI Documentation -<a name="top"></a> - -## Table of Contents - - -- [BasicTypes.proto](#BasicTypes.proto) - - [AccountID](#AccountID) - - [ContractID](#ContractID) - - [CurrentAndNextFeeSchedule](#CurrentAndNextFeeSchedule) - - [FeeComponents](#FeeComponents) - - [FeeData](#FeeData) - - [FeeSchedule](#FeeSchedule) - - [FileID](#FileID) - - [HederaFunctionality](#HederaFunctionality) (Enum) - - [Key](#Key) - - [KeyList](#KeyList) - - [NodeAddress](#NodeAddress) - - [NodeAddressBook](#NodeAddressBook) - - [RealmID](#RealmID) - - [ServicesConfigurationLis](#ServicesConfigurationLis) - - [Setting](#Setting) - - [ShardID](#ShardID) - - [Signature](#Signature) - - [SignatureList](#SignatureList) - - [SignatureMap](#SignatureMap) - - [SignaturePair](#SignaturePair) - - [ThresholdKey](#ThresholdKey) - - [ThresholdSignature](#ThresholdSignature) - - [TopicID](#TopicID) - - [TransactionFeeSchedule](#TransactionFeeSchedule) - - [TransactionID](#TransactionID) - -- [ConsensusCreateTopic.proto](#ConsensusCreateTopic.proto) - -- [ConsensusDeleteTopic.proto](#ConsensusDeleteTopic.proto) - -- [ConsensusGetTopicInfo.proto](#ConsensusGetTopicInfo.proto) - -- [ConsensusService.proto](#ConsensusService.proto) - - [ConsensusService](#ConsensusService) (Service) - -- [ConsensusSubmitMessage.proto](#ConsensusSubmitMessage.proto) - - [ConsensusSubmitMessageTransactionBody](#ConsensusSubmitMessageTransactionBody) - -- [ConsensusTopicInfo.proto](#ConsensusTopicInfo.proto) - -- [ConsensusUpdateTopic.proto](#ConsensusUpdateTopic.proto) - -- [ContractCall.proto](#ContractCall.proto) - - [ContractCallTransactionBody](#ContractCallTransactionBody) - -- [ContractCallLocal.proto](#ContractCallLocal.proto) - - [ContractCallLocalQuery](#ContractCallLocalQuery) - - [ContractCallLocalResponse](#ContractCallLocalResponse) - - [ContractFunctionResult](#ContractFunctionResult) - - [ContractLoginfo](#ContractLoginfo) - -- [ContractCreate.proto](#ContractCreate.proto) - - [ContractCreateTransactionBody](#ContractCreateTransactionBody) - -- [ContractDelete.proto](#ContractDelete.proto) - - [ContractDeleteTransactionBody](#ContractDeleteTransactionBody) - -- [ContractGetBytecode.proto](#ContractGetBytecode.proto) - - [ContractGetBytecodeQuery](#ContractGetBytecodeQuery) - - [ContractGetBytecodeResponse](#ContractGetBytecodeResponse) - -- [ContractGetInfo.proto](#ContractGetInfo.proto) - - [ContractGetInfoQuery](#ContractGetInfoQuery) - - [ContractGetInfoResponse](#ContractGetInfoResponse) - - [ContractGetInfoResponse.ContractInfo](#ContractGetInfoResponse.ContractInfo) - -- [ContractGetRecords.proto](#ContractGetRecords.proto) - - [ContractGetRecordsQuery](#ContractGetRecordsQuery) - - [ContractGetRecordsResponse](#ContractGetRecordsResponse) - -- [ContractUpdate.proto](#ContractUpdate.proto) - - [ContractUpdateTransactionBody](#ContractUpdateTransactionBody) - -- [CryptoAddClaim.proto](#CryptoAddClaim.proto) - - [Claim](#Claim) - - [CryptoAddClaimTransactionBody](#CryptoAddClaimTransactionBody) - -- [CryptoCreate.proto](#CryptoCreate.proto) - - [CryptoCreateTransactionBody](#CryptoCreateTransactionBody) - -- [CryptoDelete.proto](#CryptoDelete.proto) - - [CryptoDeleteTransactionBody](#CryptoDeleteTransactionBody) - -- [CryptoDeleteClaim.proto](#CryptoDeleteClaim.proto) - - [CryptoDeleteClaimTransactionBody](#CryptoDeleteClaimTransactionBody) - -- [CryptoGetAccountBalance.proto](#CryptoGetAccountBalance.proto) - - [CryptoGetAccountBalanceQuery](#CryptoGetAccountBalanceQuery) - - [CryptoGetAccountBalanceResponse](#CryptoGetAccountBalanceResponse) - -- [CryptoGetAccountRecords.proto](#CryptoGetAccountRecords.proto) - - [CryptoGetAccountRecordsQuery](#CryptoGetAccountRecordsQuery) - - [CryptoGetAccountRecordsResponse](#CryptoGetAccountRecordsResponse) - -- [CryptoGetClaim.proto](#CryptoGetClaim.proto) - - [CryptoGetClaimQuery](#CryptoGetClaimQuery) - - [CryptoGetClaimResponse](#CryptoGetClaimResponse) - -- [CryptoGetInfo.proto](#CryptoGetInfo.proto) - - [CryptoGetInfoQuery](#CryptoGetInfoQuery) - - [CryptoGetInfoResponse](#CryptoGetInfoResponse) - - [CryptoGetInfoResponse.AccountInfo](#CryptoGetInfoResponse.AccountInfo) - -- [CryptoGetStakers.proto](#CryptoGetStakers.proto) - - [AllProxyStakers](#AllProxyStakers) - - [CryptoGetStakersQuery](#CryptoGetStakersQuery) - - [CryptoGetStakersResponse](#CryptoGetStakersResponse) - - [ProxyStaker](#ProxyStaker) - -- [CryptoService.proto](#CryptoService.proto) - - [CryptoService](#CryptoService) (Service) - -- [CryptoTransfer.proto](#CryptoTransfer.proto) - - [AccountAmount](#AccountAmount) - - [CryptoTransferTransactionBody](#CryptoTransferTransactionBody) - - [TransferList](#TransferList) - -- [CryptoUpdate.proto](#CryptoUpdate.proto) - - [CryptoUpdateTransactionBody](#CryptoUpdateTransactionBody) - -- [Duration.proto](#Duration.proto) - - [Duration](#Duration) - -- [ExchangeRate.proto](#ExchangeRate.proto) - - [ExchangeRate](#ExchangeRate) - - [ExchangeRateSet](#ExchangeRateSet) - -- [FileAppend.proto](#FileAppend.proto) - - [FileAppendTransactionBody](#FileAppendTransactionBody) - -- [FileCreate.proto](#FileCreate.proto) - - [FileCreateTransactionBody](#FileCreateTransactionBody) - -- [FileDelete.proto](#FileDelete.proto) - - [FileDeleteTransactionBody](#FileDeleteTransactionBody) - -- [FileGetContents.proto](#FileGetContents.proto) - - [FileGetContentsQuery](#FileGetContentsQuery) - - [FileGetContentsResponse](#FileGetContentsResponse) - - [FileGetContentsResponse.FileContents](#FileGetContentsResponse.FileContents) - -- [FileGetInfo.proto](#FileGetInfo.proto) - - [FileGetInfoQuery](#FileGetInfoQuery) - - [FileGetInfoResponse](#FileGetInfoResponse) - - [FileGetInfoResponse.FileInfo](#FileGetInfoResponse.FileInfo) - -- [FileService.proto](#FileService.proto) - - [FileService](#FileService) (Service) - -- [FileUpdate.proto](#FileUpdate.proto) - - [FileUpdateTransactionBody](#FileUpdateTransactionBody) - -- [Freeze.proto](#Freeze.proto) - - [FreezeTransactionBody](#FreezeTransactionBody) - -- [FreezeService.proto](#FreezeService.proto) - - [FreezeService](#FreezeService) (Service) - -- [GetByKey.proto](#GetByKey.proto) - - [EntityID](#EntityID) - - [GetByKeyQuery](#GetByKeyQuery) - - [GetByKeyResponse](#GetByKeyResponse) - -- [GetBySolidityID.proto](#GetBySolidityID.proto) - - [GetBySolidityIDQuery](#GetBySolidityIDQuery) - - [GetBySolidityIDResponse](#GetBySolidityIDResponse) - -- [Query.proto](#Query.proto) - - [Query](#Query) - -- [QueryHeader.proto](#QueryHeader.proto) - - [QueryHeader](#QueryHeader) - - [ResponseType](#ResponseType) (Enum) - -- [Response.proto](#Response.proto) - - [Response](#Response) - -- [ResponseCode.proto](#ResponseCode.proto) - - [ResponseCodeEnum](#ResponseCodeEnum) (Enum) - -- [ResponseHeader.proto](#ResponseHeader.proto) - - [ResponseHeader](#ResponseHeader) - -- [SmartContractService.proto](#SmartContractService.proto) - - [SmartContractService](#SmartContractService) (Service) - -- [SystemDelete.proto](#SystemDelete.proto) - - [SystemDeleteTransactionBody](#SystemDeleteTransactionBody) - -- [SystemUndelete.proto](#SystemUndelete.proto) - - [SystemUndeleteTransactionBody](#SystemUndeleteTransactionBody) - -- [Timestamp.proto](#Timestamp.proto) - - [Timestamp](#Timestamp) - - [TimestampSeconds](#TimestampSeconds) - -- [Transaction.proto](#Transaction.proto) - - [Transaction](#Transaction) - -- [TransactionBody.proto](#TransactionBody.proto) - - [TransactionBody](#TransactionBody) - -- [TransactionGetFastRecord.proto](#TransactionGetFastRecord.proto) - - [TransactionGetFastRecordQuery](#TransactionGetFastRecordQuery) - - [TransactionGetFastRecordResponse](#TransactionGetFastRecordResponse) - -- [TransactionGetReceipt.proto](#TransactionGetReceipt.proto) - - [TransactionGetReceiptQuery](#TransactionGetReceiptQuery) - - [TransactionGetReceiptResponse](#TransactionGetReceiptResponse) - -- [TransactionGetRecord.proto](#TransactionGetRecord.proto) - - [TransactionGetRecordQuery](#TransactionGetRecordQuery) - - [TransactionGetRecordResponse](#TransactionGetRecordResponse) - -- [TransactionReceipt.proto](#TransactionReceipt.proto) - - [TransactionReceipt](#TransactionReceipt) - -- [TransactionRecord.proto](#TransactionRecord.proto) - - [TransactionRecord](#TransactionRecord) - -- [TransactionResponse.proto](#TransactionResponse.proto) - - [TransactionResponse](#TransactionResponse) - -<a name="BasicTypes.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## BasicTypes.proto - -<a name="AccountID"></a> - -### AccountID - The ID for an a cryptocurrency account - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | The shard number (nonnegative) | | -| realmNum | | The realm number (nonnegative) | | -| accountNum | | A nonnegative account number unique within its realm | | - - -<a name="ContractID"></a> - -### ContractID - The ID for a smart contract instance - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | The shard number (nonnegative) | | -| realmNum | | The realm number (nonnegative) | | -| contractNum | | A nonnegative number unique within its realm | | - - -<a name="CurrentAndNextFeeSchedule"></a> - -### CurrentAndNextFeeSchedule - This contains two Fee Schedules with expiry timestamp. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| currentFeeSchedule | [FeeSchedule](#FeeSchedule) | Contains current Fee Schedule | | -| nextFeeSchedule | [FeeSchedule](#FeeSchedule) | Contains next Fee Schedule | | - - -<a name="FeeComponents"></a> - -### FeeComponents - The different components used for fee calculation - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| min | | The minimum fees that needs to be paid | | -| max | | The maximum fees that can be submitted | | -| constant | | A constant determined by the business to calculate the fees | | -| bpt | | Bytes per transaction | | -| vpt | | Verifications per transaction | | -| rbh | | Ram byte seconds | | -| sbh | | Storage byte seconds | | -| gas | | Gas for the contract execution | | -| tv | | Transaction value (crypto transfers amount, tv is in tiny bars divided by 1000, rounded down) | | -| bpr | | Bytes per response | | -| sbpr | | Storage bytes per response | | - - -<a name="FeeData"></a> - -### FeeData - The total fees charged for a transaction. It contains three parts namely node data, network data and service data - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| nodedata | [FeeComponents](#FeeComponents) | Fee charged by Node for this functionality | | -| networkdata | [FeeComponents](#FeeComponents) | Fee charged for network operations by Hedera | | -| servicedata | [FeeComponents](#FeeComponents) | Fee charged for providing service by Hedera | | - - -<a name="FeeSchedule"></a> - -### FeeSchedule - The fee schedule for a specific hedera functionality and the time period this fee schedule will expire - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| transactionFeeSchedule | [TransactionFeeSchedule](#TransactionFeeSchedule) | Contains multiple functionality specific fee schedule. | | -| expiryTime | [TimestampSeconds](#TimestampSeconds) | FeeSchedule expiry time | | - - -<a name="FileID"></a> - -### FileID - The ID for a file - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | The shard number (nonnegative) | | -| realmNum | | The realm number (nonnegative) | | -| fileNum | | A nonnegative File number unique within its realm | | - - -<a name="HederaFunctionality"></a> - -### HederaFunctionality - The functionality provided by hedera hashgraph - -| Enum Name | Description | -| --------- | ----------- | -| NONE | UNSPECIFIED - Need to keep first value as unspecified because first element is ignored and not parsed (0 is ignored by parser) | -| CryptoTransfer | crypto transfer | -| CryptoUpdate | crypto update account | -| CryptoDelete | crypto delete account | -| CryptoAddClaim | crypto add claim to the account | -| CryptoDeleteClaim | crypto delete claim to the account | -| ContractCall | Smart Contract Call | -| ContractCreate | Smart Contract Create Contract | -| ContractUpdate | Smart Contract update contract | -| FileCreate | File Operation create file | -| FileAppend | File Operation append file | -| FileUpdate | File Operation update file | -| FileDelete | File Operation delete file | -| CryptoGetAccountBalance | crypto get account balance | -| CryptoGetAccountRecords | crypto get account record | -| CryptoGetInfo | Crypto get info | -| ContractCallLocal | Smart Contract Call | -| ContractGetInfo | Smart Contract get info | -| ContractGetBytecode | Smart Contract, get the byte code | -| GetBySolidityID | Smart Contract, get by solidity ID | -| GetByKey | Smart Contract, get by key | -| CryptoGetClaim | Crypto get the claim | -| CryptoGetStakers | Crypto, get the stakers for the node | -| FileGetContents | File Operations get file contents | -| FileGetInfo | File Operations get the info of the file | -| TransactionGetRecord | Crypto get the transaction records | -| ContractGetRecords | Contract get the transaction records | -| CryptoCreate | crypto create account | -| SystemDelete | system delete file | -| SystemUndelete | system undelete file | -| ContractDelete | delete contract | -| Freeze | freeze | -| CreateTransactionRecord | Create Tx Record | -| CryptoAccountAutoRenew | Crypto Auto Renew | -| ContractAutoRenew | Contract Auto Renew | -| getVersion | Get Version | -| TransactionGetReceipt | Transaction Get Receipt | -| ConsensusCreateTopic | | -| ConsensusUpdateTopic | | -| ConsensusDeleteTopic | | -| ConsensusGetTopicInfo | | -| ConsensusSubmitMessage | | - - -<a name="Key"></a> - -### Key - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| key | oneof | | | -| | contractID | [ContractID](#ContractID) | smart contract instance that is authorized as if it had signed with a key | | -| | ed25519 | | ed25519 public key bytes | | -| | RSA_3072 | | RSA-3072 public key bytes | | -| | ECDSA_384 | | ECDSA with the p-384 curve public key bytes | | -| | thresholdKey | [ThresholdKey](#ThresholdKey) | a threshold N followed by a list of M keys, any N of which are required to form a valid signature | | -| | keyList | [KeyList](#KeyList) | A list of Keys of the Key type. | | - - -<a name="KeyList"></a> - -### KeyList - A list of keys - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| keys | [Key](#Key) | list of keys | | - - -<a name="NodeAddress"></a> - -### NodeAddress - The information about a node - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| ipAddress | | The ip address of the Node with separator & octets | | -| portno | | The port number of the grpc server for the node | | -| memo | | The memo field of the node | | -| RSA_PubKey | | The RSA public key of the node. | | - - -<a name="NodeAddressBook"></a> - -### NodeAddressBook - Gives the node addresses in the address book - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| nodeAddress | [NodeAddress](#NodeAddress) | Contains multiple Node Address for the network | | - - -<a name="RealmID"></a> - -### RealmID - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | The shard number (nonnegative) | | -| realmNum | | The realm number (nonnegative) | | - - -<a name="ServicesConfigurationLis"></a> - -### ServicesConfigurationLis - - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| nameValue | [Setting](#Setting) | list of name value pairs of the application properties | | - - -<a name="Setting"></a> - -### Setting - - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| name | | name of the property | | -| value | | value of the property | | -| data | | any data associated with property | | - - -<a name="ShardID"></a> - -### ShardID - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | the shard number (nonnegative) | | - - -<a name="Signature"></a> - -### Signature - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| deprecated | | | | -| signature | oneof | | | -| | contract | | smart contract virtual signature (always length zero) | | -| | ed25519 | | ed25519 signature bytes | | -| | RSA_3072 | | RSA-3072 signature bytes | | -| | ECDSA_384 | | ECDSA p-384 signature bytes | | -| | thresholdSignature | [ThresholdSignature](#ThresholdSignature) | 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](#SignatureList) | A list of M signatures, each corresponding to a Key in a KeyList of the same length. | | - - -<a name="SignatureList"></a> - -### SignatureList - The signatures corresponding to a KeyList of the same length. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| deprecated | | | | -| sigs | [Signature](#Signature) | each signature corresponds to a Key in the KeyList | | - - -<a name="SignatureMap"></a> - -### SignatureMap - A set of signatures corresponding to every unique public key used to sign a given transaction. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| sigPair | [SignaturePair](#SignaturePair) | Each signature pair corresponds to a unique Key required to sign the transaction. | | - - -<a name="SignaturePair"></a> - -### SignaturePair - The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| pubKeyPrefix | | First few bytes of the public key | | -| signature | oneof | | | -| | contract | | smart contract virtual signature (always length zero) | | -| | ed25519 | | ed25519 signature | | -| | RSA_3072 | | RSA-3072 signature | | -| | ECDSA_384 | | ECDSA p-384 signature | | - - -<a name="ThresholdKey"></a> - -### ThresholdKey - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| threshold | | A valid signature set must have at least this many signatures | | -| keys | [KeyList](#KeyList) | List of all the keys that can sign | | - - -<a name="ThresholdSignature"></a> - -### ThresholdSignature - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| deprecated | | | | -| sigs | [SignatureList](#SignatureList) | for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null | | - - -<a name="TopicID"></a> - -### TopicID - Unique identifier for a topic (used by the consensus service) - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| shardNum | | The shard number (nonnegative) | | -| realmNum | | The realm number (nonnegative) | | -| topicNum | | Unique topic identifier within a realm (nonnegative). | | - - -<a name="TransactionFeeSchedule"></a> - -### TransactionFeeSchedule - The fees for a specific transaction or query based on the fee data. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| hederaFunctionality | [HederaFunctionality](#HederaFunctionality) | Specific Transaction or Query | | -| feeData | [FeeData](#FeeData) | The fee information about the query/data | | - - -<a name="TransactionID"></a> - -### TransactionID - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| transactionValidStart | [Timestamp](#Timestamp) | The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid | | -| accountID | [AccountID](#AccountID) | The Account ID that paid for this transaction | | - - -<a name="ConsensusCreateTopic.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusCreateTopic.proto - -<a name="ConsensusDeleteTopic.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusDeleteTopic.proto - -<a name="ConsensusGetTopicInfo.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusGetTopicInfo.proto - -<a name="ConsensusService.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusService.proto - -<a name="ConsensusService"></a> - -### ConsensusService - - -| RPC | Request | Response | Comments | -| --- | ------- | -------- | -------- | -| createTopic | Transaction | TransactionResponse); | -| updateTopic | Transaction | TransactionResponse); | -| deleteTopic | Transaction | TransactionResponse); | -| getTopicInfo | Query | Response); | -| submitMessage | Transaction | TransactionResponse); | - - -<a name="ConsensusSubmitMessage.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusSubmitMessage.proto - -<a name="ConsensusSubmitMessageTransactionBody"></a> - -### ConsensusSubmitMessageTransactionBody - - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| topicID | [TopicID](#TopicID) | Topic to submit message to. | | -| message | | Message to be submitted. Max size of the Transaction (including signatures) is 4kB. | | - - -<a name="ConsensusTopicInfo.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusTopicInfo.proto - -<a name="ConsensusUpdateTopic.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ConsensusUpdateTopic.proto - -<a name="ContractCall.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractCall.proto - -<a name="ContractCallTransactionBody"></a> - -### ContractCallTransactionBody - Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | the contract instance to call, in the format used in transactions | | -| gas | | the maximum amount of gas to use for the call | | -| amount | | number of tinybars sent (the function must be payable if this is nonzero) | | -| functionParameters | | which function to call, and the parameters to pass to the function | | - - -<a name="ContractCallLocal.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractCallLocal.proto - -<a name="ContractCallLocalQuery"></a> - -### ContractCallLocalQuery - Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). The payment must cover the fees and all of the gas offered. | | -| contractID | [ContractID](#ContractID) | the contract instance to call, in the format used in transactions | | -| gas | | the amount of gas to use for the call. All of the gas offered will be charged for. | | -| functionParameters | | which function to call, and the parameters to pass to the function | | -| maxResultSize | | max number of bytes that the result might include. The run will fail if it would have returned more than this number of bytes. | | - - -<a name="ContractCallLocalResponse"></a> - -### ContractCallLocalResponse - Response when the client sends the node ContractCallLocalQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| functionResult | [ContractFunctionResult](#ContractFunctionResult) | the value returned by the function (if it completed and didn't fail) | | - - -<a name="ContractFunctionResult"></a> - -### ContractFunctionResult - The result returned by a call to a smart contract function. This is part of the response to a ContractCallLocal query, and is in the record for a ContractCall or ContractCreateInstance transaction. The ContractCreateInstance transaction record has the results of the call to the constructor. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | the smart contract instance whose function was called | | -| contractCallResult | | the result returned by the function | | -| errorMessage | | message In case there was an error during smart contract execution | | -| bloom | | bloom filter for record | | -| gasUsed | | units of gas used to execute contract | | -| logInfo | [ContractLoginfo](#ContractLoginfo) | the log info for events returned by the function | | - - -<a name="ContractLoginfo"></a> - -### ContractLoginfo - The log information for an event returned by a smart contract function call. One function call may return several such events. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | address of a contract that emitted the event | | -| bloom | | bloom filter for a particular log | | -| topic | | topics of a particular event | | -| data | | event data | | - - -<a name="ContractCreate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractCreate.proto - -<a name="ContractCreateTransactionBody"></a> - -### ContractCreateTransactionBody - Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | the file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: | | -| adminKey | [Key](#Key) | the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. | | -| gas | | gas to run the constructor | | -| initialBalance | | initial number of tinybars to put into the cryptocurrency account associated with and owned by the smart contract | | -| proxyAccountID | [AccountID](#AccountID) | 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. | | -| autoRenewPeriod | [Duration](#Duration) | the instance will charge its account every this many seconds to renew for this long | | -| constructorParameters | | parameters to pass to the constructor | | -| shardID | [ShardID](#ShardID) | shard in which to create this | | -| realmID | [RealmID](#RealmID) | realm in which to create this (leave this null to create a new realm) | | -| newRealmAdminKey | [Key](#Key) | if realmID is null, then this the admin key for the new realm that will be created | | -| memo | | the memo that was submitted as part of the contract (max 100 bytes) | | - - -<a name="ContractDelete.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractDelete.proto - -<a name="ContractDeleteTransactionBody"></a> - -### ContractDeleteTransactionBody - Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | The Contract ID instance to delete (this can't be changed) | | -| obtainers | oneof | | | -| | transferAccountID | [AccountID](#AccountID) | The account ID which will receive all remaining hbars | | -| | transferContractID | [ContractID](#ContractID) | The contract ID which will receive all remaining hbars | | - - -<a name="ContractGetBytecode.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractGetBytecode.proto - -<a name="ContractGetBytecodeQuery"></a> - -### ContractGetBytecodeQuery - Get the bytecode for a smart contract instance - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| contractID | [ContractID](#ContractID) | the contract for which information is requested | | - - -<a name="ContractGetBytecodeResponse"></a> - -### ContractGetBytecodeResponse - Response when the client sends the node ContractGetBytecodeQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| bytecode | | the bytecode | | - - -<a name="ContractGetInfo.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractGetInfo.proto - -<a name="ContractGetInfoQuery"></a> - -### ContractGetInfoQuery - Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| contractID | [ContractID](#ContractID) | the contract for which information is requested | | - - -<a name="ContractGetInfoResponse"></a> - -### ContractGetInfoResponse - Response when the client sends the node ContractGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| contractInfo | [ContractGetInfoResponse.ContractInfo](#ContractGetInfoResponse.ContractInfo) | the information about this contract instance (a state proof can be generated for this) | | - - -<a name="ContractGetInfoResponse.ContractInfo"></a> - -### ContractGetInfoResponse.ContractInfo - Response when the client sends the node ContractGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | ID of the contract instance, in the format used in transactions | | -| accountID | [AccountID](#AccountID) | ID of the cryptocurrency account owned by the contract instance, in the format used in transactions | | -| contractAccountID | | ID of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity | | -| adminKey | [Key](#Key) | the state of the instance and its fields can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. Note that if it is created with no admin keys, then there is no administrator to authorize changing the admin keys, so there can never be any admin keys for that instance. | | -| expirationTime | [Timestamp](#Timestamp) | the current time at which this contract instance (and its account) is set to expire | | -| autoRenewPeriod | [Duration](#Duration) | the expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If the account is empty when it expires, then it is deleted. | | -| storage | | number of bytes of storage being used by this instance (which affects the cost to extend the expiration time) | | -| memo | | the memo associated with the contract (max 100 bytes) | | -| balance | | The current balance, in tinybars | | - - -<a name="ContractGetRecords.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractGetRecords.proto - -<a name="ContractGetRecordsQuery"></a> - -### ContractGetRecordsQuery - Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| contractID | [ContractID](#ContractID) | The smart contract instance for which the records should be retrieved | | - - -<a name="ContractGetRecordsResponse"></a> - -### ContractGetRecordsResponse - Response when the client sends the node ContractGetRecordsQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| contractID | [ContractID](#ContractID) | The smart contract instance that this record is for | | -| records | [TransactionRecord](#TransactionRecord) | List of records, each with contractCreateResult or contractCallResult as its body | | - - -<a name="ContractUpdate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ContractUpdate.proto - -<a name="ContractUpdateTransactionBody"></a> - -### ContractUpdateTransactionBody - Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| contractID | [ContractID](#ContractID) | The Contract ID instance to update (this can't be changed) | | -| expirationTime | [Timestamp](#Timestamp) | Extend the expiration of the instance and its account to this time (no effect if it already is this time or later) | | -| adminKey | [Key](#Key) | The state of the instance can be modified arbitrarily if this key signs a transaction to modify it. If this is null, then such modifications are not possible, and there is no administrator that can override the normal operation of this smart contract instance. | | -| proxyAccountID | [AccountID](#AccountID) | 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. | | -| autoRenewPeriod | [Duration](#Duration) | The instance will charge its account every this many seconds to renew for this long | | -| fileID | [FileID](#FileID) | The file ID of file containing the smart contract byte code. A copy will be made and held by the contract instance, and have the same expiration time as the instance. The file is referenced one of two ways: | | -| memo | | The memo associated with the contract (max 100 bytes) | | - - -<a name="CryptoAddClaim.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoAddClaim.proto - -<a name="Claim"></a> - -### Claim - A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountID | [AccountID](#AccountID) | the account to which the claim is attached | | -| hash | | 48 byte SHA-384 hash (presumably of some kind of credential or certificate) | | -| keys | [KeyList](#KeyList) | list of keys: all must sign the transaction to attach the claim, and any one of them can later delete it. Each "key" can actually be a threshold key containing multiple other keys (including other threshold keys). | | -| claimDuration | [Duration](#Duration) | the duration for which the claim will remain valid | | - - -<a name="CryptoAddClaimTransactionBody"></a> - -### CryptoAddClaimTransactionBody - Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| claim | [Claim](#Claim) | A hash of some credential/certificate, along with the keys that authorized it and are allowed to delete it | | - - -<a name="CryptoCreate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoCreate.proto - -<a name="CryptoCreateTransactionBody"></a> - -### CryptoCreateTransactionBody - Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| key | [Key](#Key) | 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. | | -| initialBalance | | The initial number of tinybars to put into the account | | -| proxyAccountID | [AccountID](#AccountID) | 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. | | -| sendRecordThreshold | | The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction | | -| receiveRecordThreshold | | The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction | | -| receiverSigRequired | | If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) | | -| autoRenewPeriod | [Duration](#Duration) | 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](#ShardID) | The shard in which this account is created | | -| realmID | [RealmID](#RealmID) | The realm in which this account is created (leave this null to create a new realm) | | -| newRealmAdminKey | [Key](#Key) | If realmID is null, then this the admin key for the new realm that will be created | | - - -<a name="CryptoDelete.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoDelete.proto - -<a name="CryptoDeleteTransactionBody"></a> - -### CryptoDeleteTransactionBody - Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| transferAccountID | [AccountID](#AccountID) | The account ID which will receive all remaining hbars | | -| deleteAccountID | [AccountID](#AccountID) | The account ID which should be deleted | | - - -<a name="CryptoDeleteClaim.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoDeleteClaim.proto - -<a name="CryptoDeleteClaimTransactionBody"></a> - -### CryptoDeleteClaimTransactionBody - Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountIDToDeleteFrom | [AccountID](#AccountID) | The account ID that should have a claim deleted | | -| hashToDelete | | The hash in the claim to delete (a SHA-384 hash, 48 bytes) | | - - -<a name="CryptoGetAccountBalance.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoGetAccountBalance.proto - -<a name="CryptoGetAccountBalanceQuery"></a> - -### CryptoGetAccountBalanceQuery - Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| balanceSource | oneof | | | -| | accountID | [AccountID](#AccountID) | The account ID for which information is requested | | -| | contractID | [ContractID](#ContractID) | The account ID for which information is requested | | - - -<a name="CryptoGetAccountBalanceResponse"></a> - -### CryptoGetAccountBalanceResponse - Response when the client sends the node CryptoGetAccountBalanceQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| accountID | [AccountID](#AccountID) | The account ID that is being described (this is useful with state proofs, for proving to a third party) | | -| balance | | The current balance, in tinybars | | - - -<a name="CryptoGetAccountRecords.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoGetAccountRecords.proto - -<a name="CryptoGetAccountRecordsQuery"></a> - -### CryptoGetAccountRecordsQuery - Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| accountID | [AccountID](#AccountID) | The account ID for which the records should be retrieved | | - - -<a name="CryptoGetAccountRecordsResponse"></a> - -### CryptoGetAccountRecordsResponse - Response when the client sends the node CryptoGetAccountRecordsQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| accountID | [AccountID](#AccountID) | The account that this record is for | | -| records | [TransactionRecord](#TransactionRecord) | List of records, each with CryptoRecordBody as their body | | - - -<a name="CryptoGetClaim.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoGetClaim.proto - -<a name="CryptoGetClaimQuery"></a> - -### CryptoGetClaimQuery - Get a single claim attached to an account, or return null if it does not exist. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| accountID | [AccountID](#AccountID) | The account ID to which the claim was attached | | -| hash | | The hash of the claim | | - - -<a name="CryptoGetClaimResponse"></a> - -### CryptoGetClaimResponse - Response when the client sends the node CryptoGetClaimQuery. If the claim exists, there can be a state proof for that single claim. If the claim doesn't exist, then the state proof must be obtained for the account as a whole, which lists all the attached claims, which then proves that any claim not on the list must not exist. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| claim | [Claim](#Claim) | The claim (account, hash, keys), or null if there is no Claim with the given hash attached to the given account | | - - -<a name="CryptoGetInfo.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoGetInfo.proto - -<a name="CryptoGetInfoQuery"></a> - -### CryptoGetInfoQuery - Get all the information about an account, including the balance. This does not get the list of account records. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| accountID | [AccountID](#AccountID) | The account ID for which information is requested | | - - -<a name="CryptoGetInfoResponse"></a> - -### CryptoGetInfoResponse - Response when the client sends the node CryptoGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| accountInfo | [CryptoGetInfoResponse.AccountInfo](#CryptoGetInfoResponse.AccountInfo) | Info about the account (a state proof can be generated for this) | | - - -<a name="CryptoGetInfoResponse.AccountInfo"></a> - -### CryptoGetInfoResponse.AccountInfo - Response when the client sends the node CryptoGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountID | [AccountID](#AccountID) | The account ID for which this information applies | | -| contractAccountID | | The Contract Account ID comprising of both the contract instance and the cryptocurrency account owned by the contract instance, in the format used by Solidity | | -| deleted | | If true, then this account has been deleted, it will disappear when it expires, and all transactions for it will fail except the transaction to extend its expiration date | | -| proxyAccountID | [AccountID](#AccountID) | The Account ID of the account to which this 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. | | -| proxyReceived | | The total number of tinybars proxy staked to this account | | -| key | [Key](#Key) | The key for the account, which must sign in order to transfer out, or to modify the account in any way other than extending its expiration date. | | -| balance | | The current balance of account in tinybars | | -| generateSendRecordThreshold | | The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any send/withdraw transaction. | | -| generateReceiveRecordThreshold | | The threshold amount (in tinybars) for which an account record is created (and this account charged for them) for any transaction above this amount. | | -| receiverSigRequired | | If true, no transaction can transfer to this account unless signed by this account's key | | -| expirationTime | [Timestamp](#Timestamp) | The TimeStamp time at which this account is set to expire | | -| autoRenewPeriod | [Duration](#Duration) | The duration for expiration time will extend every this many seconds. If there are insufficient funds, then it extends as long as possible. If it is empty when it expires, then it is deleted. | | -| claims | [Claim](#Claim) | All of the claims attached to the account (each of which is a hash along with the keys that authorized it and can delete it ) | | - - -<a name="CryptoGetStakers.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoGetStakers.proto - -<a name="AllProxyStakers"></a> - -### AllProxyStakers - all of the accounts proxy staking to a given account, and the amounts proxy staked - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountID | [AccountID](#AccountID) | The Account ID that is being proxy staked to | | -| proxyStaker | [ProxyStaker](#ProxyStaker) | Each of the proxy staking accounts, and the amount they are proxy staking | | - - -<a name="CryptoGetStakersQuery"></a> - -### CryptoGetStakersQuery - Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| accountID | [AccountID](#AccountID) | The Account ID for which the records should be retrieved | | - - -<a name="CryptoGetStakersResponse"></a> - -### CryptoGetStakersResponse - Response when the client sends the node CryptoGetStakersQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| stakers | [AllProxyStakers](#AllProxyStakers) | List of accounts proxy staking to this account, and the amount each is currently proxy staking | | - - -<a name="ProxyStaker"></a> - -### ProxyStaker - information about a single account that is proxy staking - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountID | [AccountID](#AccountID) | The Account ID that is proxy staking | | -| amount | | The number of hbars that are currently proxy staked | | - - -<a name="CryptoService.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoService.proto - -<a name="CryptoService"></a> - -### CryptoService - - -| RPC | Request | Response | Comments | -| --- | ------- | -------- | -------- | -| createAccount | Transaction | TransactionResponse | Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse | -| updateAccount | Transaction | TransactionResponse | Updates an account by submitting the transaction. The grpc server returns the TransactionResponse | -| cryptoTransfer | Transaction | TransactionResponse | Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse | -| cryptoDelete | Transaction | TransactionResponse | Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse | -| addClaim | Transaction | TransactionResponse | Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse | -| deleteClaim | Transaction | TransactionResponse | Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse | -| getClaim | Query | Response | Retrieves the claim for an account by submitting the query. | -| getAccountRecords | Query | Response | Retrieves the record(fetch by AccountID ID) for an account by submitting the query. | -| cryptoGetBalance | Query | Response | Retrieves the balance for an account by submitting the query. | -| getAccountInfo | Query | Response | Retrieves the account information for an account by submitting the query. | -| getTransactionReceipts | Query | Response | Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee. | -| getFastTransactionRecord | Query | Response | Retrieves the transaction record by TxID which last for 180sec only for no fee. | -| getTxRecordByTxID | Query | Response | Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query. | -| getStakersByAccountID | Query | Response | Retrieves the stakers for a node by account ID by submitting the query. | - - -<a name="CryptoTransfer.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoTransfer.proto - -<a name="AccountAmount"></a> - -### AccountAmount - An account, and the amount that it sends or receives during a cryptocurrency transfer. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountID | [AccountID](#AccountID) | The Account ID that sends or receives cryptocurrency | | -| amount | [sint64](#sint64) | The amount of tinybars that the account sends(negative) or receives(positive) | | - - -<a name="CryptoTransferTransactionBody"></a> - -### CryptoTransferTransactionBody - 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 to do the withdrawal, 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| transfers | [TransferList](#TransferList) | Accounts and amounts to transfer | | - - -<a name="TransferList"></a> - -### TransferList - A list of accounts and amounts to transfer out of each account (negative) or into it (positive). - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountAmounts | [AccountAmount](#AccountAmount) | 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 name="CryptoUpdate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## CryptoUpdate.proto - -<a name="CryptoUpdateTransactionBody"></a> - -### CryptoUpdateTransactionBody - Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| accountIDToUpdate | [AccountID](#AccountID) | The account ID which is being updated in this transaction | | -| key | [Key](#Key) | The new key | | -| proxyAccountID | [AccountID](#AccountID) | 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. | | -| proxyFraction | | [Deprecated]. payments earned from proxy staking are shared between the node and this account, with proxyFraction / 10000 going to this account | | -| sendRecordThresholdField | oneof | | | -| | sendRecordThreshold | | [Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction | | -| | sendRecordThresholdWrapper | [google.protobuf.UInt64Value](#google.protobuf.UInt64Value) | The new threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction | | -| receiveRecordThresholdField | oneof | | | -| | receiveRecordThreshold | | [Deprecated]. The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. | | -| | receiveRecordThresholdWrapper | [google.protobuf.UInt64Value](#google.protobuf.UInt64Value) | The new threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction. | | -| autoRenewPeriod | [Duration](#Duration) | The duration in which it will automatically extend the expiration period. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted. | | -| expirationTime | [Timestamp](#Timestamp) | The new expiration time to extend to (ignored if equal to or before the current one) | | -| receiverSigRequiredField | oneof | | | -| | receiverSigRequired | | [Deprecated] Do NOT use this field to set a false value because the server cannot distinguish from the default value. Use receiverSigRequiredWrapper field for this purpose. | | -| | receiverSigRequiredWrapper | [google.protobuf.BoolValue](#google.protobuf.BoolValue) | If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals) | | - - -<a name="Duration.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Duration.proto - -<a name="Duration"></a> - -### Duration - The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| seconds | | number of seconds | | - - -<a name="ExchangeRate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ExchangeRate.proto - -<a name="ExchangeRate"></a> - -### ExchangeRate - Values from these proto denotes habr and cents(USD) conversion - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| hbarEquiv | | value which denote habar equivalent to cent | | -| centEquiv | | value which denote cents (USD) equivalent to Hbar} | | -| expirationTime | [TimestampSeconds](#TimestampSeconds) | expired time in seconds for this exchange rate | | - - -<a name="ExchangeRateSet"></a> - -### ExchangeRateSet - Two sets of exchange rate - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| currentRate | [ExchangeRate](#ExchangeRate) | Current rate of Exchange of Hbar to cents | | -| nextRate | [ExchangeRate](#ExchangeRate) | Next rate exchange of Hbar to cents | | - - -<a name="FileAppend.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileAppend.proto - -<a name="FileAppendTransactionBody"></a> - -### FileAppendTransactionBody - Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | The file ID of the file to which the bytes are appended to | | -| contents | | The bytes to append to the contents of the file | | - - -<a name="FileCreate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileCreate.proto - -<a name="FileCreateTransactionBody"></a> - -### FileCreateTransactionBody - Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| expirationTime | [Timestamp](#Timestamp) | The time at which this file should expire (unless FileUpdateTransaction is used before then to extend its life) | | -| keys | [KeyList](#KeyList) | All these keys must sign to create or modify the file. Any one of them can sign to delete the file. | | -| contents | | The bytes that are the contents of the file | | -| shardID | [ShardID](#ShardID) | Shard in which this file is created | | -| realmID | [RealmID](#RealmID) | The Realm in which to the file is created (leave this null to create a new realm) | | -| newRealmAdminKey | [Key](#Key) | If realmID is null, then this the admin key for the new realm that will be created | | - - -<a name="FileDelete.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileDelete.proto - -<a name="FileDeleteTransactionBody"></a> - -### FileDeleteTransactionBody - Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | The file to delete. It will be marked as deleted until it expires. Then it will disappear. | | - - -<a name="FileGetContents.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileGetContents.proto - -<a name="FileGetContentsQuery"></a> - -### FileGetContentsQuery - Get the contents of a file. The content field is empty (no bytes) if the file is empty. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| fileID | [FileID](#FileID) | The file ID of the file whose contents are requested | | - - -<a name="FileGetContentsResponse"></a> - -### FileGetContentsResponse - Response when the client sends the node FileGetContentsQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| fileContents | [FileGetContentsResponse.FileContents](#FileGetContentsResponse.FileContents) | the file ID and contents (a state proof can be generated for this) | | - - -<a name="FileGetContentsResponse.FileContents"></a> - -### FileGetContentsResponse.FileContents - Response when the client sends the node FileGetContentsQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | The file ID of the file whose contents are being returned | | -| contents | | The bytes contained in the file | | - - -<a name="FileGetInfo.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileGetInfo.proto - -<a name="FileGetInfoQuery"></a> - -### FileGetInfoQuery - Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| fileID | [FileID](#FileID) | The file ID of the file for which information is requested | | - - -<a name="FileGetInfoResponse"></a> - -### FileGetInfoResponse - Response when the client sends the node FileGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| fileInfo | [FileGetInfoResponse.FileInfo](#FileGetInfoResponse.FileInfo) | The information about the file (a state proof can be generated for this) | | - - -<a name="FileGetInfoResponse.FileInfo"></a> - -### FileGetInfoResponse.FileInfo - Response when the client sends the node FileGetInfoQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | The file ID of the file for which information is requested | | -| size | | Number of bytes in contents | | -| expirationTime | [Timestamp](#Timestamp) | The current time at which this account is set to expire | | -| deleted | | True if deleted but not yet expired | | -| keys | [KeyList](#KeyList) | One of these keys must sign in order to modify or delete the file | | - - -<a name="FileService.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileService.proto - -<a name="FileService"></a> - -### FileService - - -| RPC | Request | Response | Comments | -| --- | ------- | -------- | -------- | -| createFile | Transaction | TransactionResponse | Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse | -| updateFile | Transaction | TransactionResponse | Updates a file by submitting the transaction. The grpc server returns the TransactionResponse | -| deleteFile | Transaction | TransactionResponse | Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse | -| appendContent | Transaction | TransactionResponse | Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse | -| getFileContent | Query | Response | Retrieves the file content by submitting the query. The grpc server returns the Response | -| getFileInfo | Query | Response | Retrieves the file information by submitting the query. The grpc server returns the Response | -| systemDelete | Transaction | TransactionResponse | Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | -| systemUndelete | Transaction | TransactionResponse | UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | - - -<a name="FileUpdate.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FileUpdate.proto - -<a name="FileUpdateTransactionBody"></a> - -### FileUpdateTransactionBody - Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| fileID | [FileID](#FileID) | The file ID of the file to update | | -| expirationTime | [Timestamp](#Timestamp) | The new time at which it should expire (ignored if not later than the current value) | | -| keys | [KeyList](#KeyList) | The keys that can modify or delete the file | | -| contents | | The new file contents. All the bytes in the old contents are discarded. | | - - -<a name="Freeze.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Freeze.proto - -<a name="FreezeTransactionBody"></a> - -### FreezeTransactionBody - Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| startHour | | The start hour (in UTC time), a value between 0 and 23 | | -| startMin | | The start minute (in UTC time), a value between 0 and 59 | | -| endHour | | The end hour (in UTC time), a value between 0 and 23 | | -| endMin | | The end minute (in UTC time), a value between 0 and 59 | | - - -<a name="FreezeService.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## FreezeService.proto - -<a name="FreezeService"></a> - -### FreezeService - - -| RPC | Request | Response | Comments | -| --- | ------- | -------- | -------- | -| freeze | Transaction | TransactionResponse | Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse | - - -<a name="GetByKey.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## GetByKey.proto - -<a name="EntityID"></a> - -### EntityID - the ID for a single entity (account, claim, file, or smart contract instance) - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| entity | oneof | | | -| | accountID | [AccountID](#AccountID) | The Account ID for the cryptocurrency account | | -| | claim | [Claim](#Claim) | The claim details attached to an account | | -| | fileID | [FileID](#FileID) | The file ID of the file | | -| | contractID | [ContractID](#ContractID) | The smart contract ID that identifies instance | | - - -<a name="GetByKeyQuery"></a> - -### GetByKeyQuery - Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| key | [Key](#Key) | The key to search for. It must not contain a contractID nor a ThresholdSignature. | | - - -<a name="GetByKeyResponse"></a> - -### GetByKeyResponse - Response when the client sends the node GetByKeyQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| entities | [EntityID](#EntityID) | The list of entities that include this public key in their associated Key list | | - - -<a name="GetBySolidityID.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## GetBySolidityID.proto - -<a name="GetBySolidityIDQuery"></a> - -### GetBySolidityIDQuery - Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| solidityID | | The ID in the format used by Solidity | | - - -<a name="GetBySolidityIDResponse"></a> - -### GetBySolidityIDResponse - Response when the client sends the node GetBySolidityIDQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| accountID | [AccountID](#AccountID) | The Account ID for the cryptocurrency account | | -| fileID | [FileID](#FileID) | The file Id for the file | | -| contractID | [ContractID](#ContractID) | A smart contract ID for the instance (if this is included, then the associated accountID will also be included) | | - - -<a name="Query.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Query.proto - -<a name="Query"></a> - -### Query - A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| query | oneof | | | -| | getByKey | [GetByKeyQuery](#GetByKeyQuery) | Get all entities associated with a given key | | -| | getBySolidityID | [GetBySolidityIDQuery](#GetBySolidityIDQuery) | Get the IDs in the format used in transactions, given the format used in Solidity | | -| | contractCallLocal | [ContractCallLocalQuery](#ContractCallLocalQuery) | Call a function of a smart contract instance | | -| | contractGetInfo | [ContractGetInfoQuery](#ContractGetInfoQuery) | Get information about a smart contract instance | | -| | contractGetBytecode | [ContractGetBytecodeQuery](#ContractGetBytecodeQuery) | Get bytecode used by a smart contract instance | | -| | ContractGetRecords | [ContractGetRecordsQuery](#ContractGetRecordsQuery) | Get Records of the contract instance | | -| | cryptogetAccountBalance | [CryptoGetAccountBalanceQuery](#CryptoGetAccountBalanceQuery) | Get the current balance in a cryptocurrency account | | -| | cryptoGetAccountRecords | [CryptoGetAccountRecordsQuery](#CryptoGetAccountRecordsQuery) | Get all the records that currently exist for transactions involving an account | | -| | cryptoGetInfo | [CryptoGetInfoQuery](#CryptoGetInfoQuery) | Get all information about an account | | -| | cryptoGetClaim | [CryptoGetClaimQuery](#CryptoGetClaimQuery) | Get a single claim from a single account (or null if it doesn't exist) | | -| | cryptoGetProxyStakers | [CryptoGetStakersQuery](#CryptoGetStakersQuery) | Get all the accounts that proxy stake to a given account, and how much they proxy stake (not yet implemented in the current API) | | -| | fileGetContents | [FileGetContentsQuery](#FileGetContentsQuery) | Get the contents of a file (the bytes stored in it) | | -| | fileGetInfo | [FileGetInfoQuery](#FileGetInfoQuery) | Get information about a file, such as its expiration date | | -| | transactionGetReceipt | [TransactionGetReceiptQuery](#TransactionGetReceiptQuery) | Get a receipt for a transaction (lasts 180 seconds) | | -| | transactionGetRecord | [TransactionGetRecordQuery](#TransactionGetRecordQuery) | Get a record for a transaction (lasts 1 hour) | | -| | transactionGetFastRecord | [TransactionGetFastRecordQuery](#TransactionGetFastRecordQuery) | Get a record for a transaction (lasts 180 seconds) | | -| | consensusGetTopicInfo | [ConsensusGetTopicInfoQuery](#ConsensusGetTopicInfoQuery) | Get the parameters of and state of a consensus topic. | | - - -<a name="QueryHeader.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## QueryHeader.proto - -<a name="QueryHeader"></a> - -### QueryHeader - Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| payment | [Transaction](#Transaction) | A signed CryptoTransferTransaction to pay the node a fee for handling this query | | -| responseType | [ResponseType](#ResponseType) | The requested response, asking for cost, state proof, both, or neither | | - - -<a name="ResponseType"></a> - -### ResponseType - The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. - -| Enum Name | Description | -| --------- | ----------- | -| ANSWER_ONLY | Response returns answer | -| ANSWER_STATE_PROOF | Response returns both answer and state proof | -| COST_ANSWER | Response returns the cost of answer | -| COST_ANSWER_STATE_PROOF | Response returns the total cost of answer and state proof | - - -<a name="Response.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Response.proto - -<a name="Response"></a> - -### Response - A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| response | oneof | | | -| | getByKey | [GetByKeyResponse](#GetByKeyResponse) | Get all entities associated with a given key | | -| | getBySolidityID | [GetBySolidityIDResponse](#GetBySolidityIDResponse) | Get the IDs in the format used in transactions, given the format used in Solidity | | -| | contractCallLocal | [ContractCallLocalResponse](#ContractCallLocalResponse) | Response to call a function of a smart contract instance | | -| | contractGetBytecodeResponse | [ContractGetBytecodeResponse](#ContractGetBytecodeResponse) | Get the bytecode for a smart contract instance | | -| | contractGetInfo | [ContractGetInfoResponse](#ContractGetInfoResponse) | Get information about a smart contract instance | | -| | contractGetRecordsResponse | [ContractGetRecordsResponse](#ContractGetRecordsResponse) | Get all existing records for a smart contract instance | | -| | cryptogetAccountBalance | [CryptoGetAccountBalanceResponse](#CryptoGetAccountBalanceResponse) | Get the current balance in a cryptocurrency account | | -| | cryptoGetAccountRecords | [CryptoGetAccountRecordsResponse](#CryptoGetAccountRecordsResponse) | Get all the records that currently exist for transactions involving an account | | -| | cryptoGetInfo | [CryptoGetInfoResponse](#CryptoGetInfoResponse) | Get all information about an account | | -| | cryptoGetClaim | [CryptoGetClaimResponse](#CryptoGetClaimResponse) | Get a single claim from a single account (or null if it doesn't exist) | | -| | cryptoGetProxyStakers | [CryptoGetStakersResponse](#CryptoGetStakersResponse) | Get all the accounts that proxy stake to a given account, and how much they proxy stake | | -| | fileGetContents | [FileGetContentsResponse](#FileGetContentsResponse) | Get the contents of a file (the bytes stored in it) | | -| | fileGetInfo | [FileGetInfoResponse](#FileGetInfoResponse) | Get information about a file, such as its expiration date | | -| | transactionGetReceipt | [TransactionGetReceiptResponse](#TransactionGetReceiptResponse) | Get a receipt for a transaction (lasts 180 seconds) | | -| | transactionGetRecord | [TransactionGetRecordResponse](#TransactionGetRecordResponse) | Get a record for a transaction (lasts 1 hour) | | -| | transactionGetFastRecord | [TransactionGetFastRecordResponse](#TransactionGetFastRecordResponse) | Get a record for a transaction (lasts 180 seconds) | | -| | consensusGetTopicInfo | [ConsensusGetTopicInfoResponse](#ConsensusGetTopicInfoResponse) | Parameters of and state of a consensus topic.. | | - - -<a name="ResponseCode.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ResponseCode.proto - -<a name="ResponseCodeEnum"></a> - -### ResponseCodeEnum - - -| Enum Name | Description | -| --------- | ----------- | -| OK | The transaction passed the precheck validations. | -| INVALID_TRANSACTION | For any error not handled by specific error codes listed below. | -| PAYER_ACCOUNT_NOT_FOUND | Payer account does not exist. | -| INVALID_NODE_ACCOUNT | Node Account provided does not match the node account of the node the transaction was submitted to. | -| TRANSACTION_EXPIRED | Pre-Check error when TransactionValidStart + transactionValidDuration is less than current consensus time. | -| INVALID_TRANSACTION_START | Transaction start time is greater than current consensus time | -| INVALID_TRANSACTION_DURATION | valid transaction duration is a positive non zero number that does not exceed 120 seconds | -| INVALID_SIGNATURE | The transaction signature is not valid | -| MEMO_TOO_LONG | Transaction memo size exceeded 100 bytes | -| INSUFFICIENT_TX_FEE | The fee provided in the transaction is insufficient for this type of transaction | -| INSUFFICIENT_PAYER_BALANCE | The payer account has insufficient cryptocurrency to pay the transaction fee | -| DUPLICATE_TRANSACTION | This transaction ID is a duplicate of one that was submitted to this node or reached consensus in the last 180 seconds (receipt period) | -| BUSY | If API is throttled out | -| NOT_SUPPORTED | The API is not currently supported | -| INVALID_FILE_ID | The file id is invalid or does not exist | -| INVALID_ACCOUNT_ID | The account id is invalid or does not exist | -| INVALID_CONTRACT_ID | The contract id is invalid or does not exist | -| INVALID_TRANSACTION_ID | Transaction id is not valid | -| RECEIPT_NOT_FOUND | Receipt for given transaction id does not exist | -| RECORD_NOT_FOUND | Record for given transaction id does not exist | -| INVALID_SOLIDITY_ID | The solidity id is invalid or entity with this solidity id does not exist | -| UNKNOWN | Transaction hasn't yet reached consensus, or has already expired | -| SUCCESS | The transaction succeeded | -| FAIL_INVALID | There was a system error and the transaction failed because of invalid request parameters. | -| FAIL_FEE | There was a system error while performing fee calculation, reserved for future. | -| FAIL_BALANCE | There was a system error while performing balance checks, reserved for future. | -| KEY_REQUIRED | Key not provided in the transaction body | -| BAD_ENCODING | Unsupported algorithm/encoding used for keys in the transaction | -| INSUFFICIENT_ACCOUNT_BALANCE | When the account balance is not sufficient for the transfer | -| INVALID_SOLIDITY_ADDRESS | During an update transaction when the system is not able to find the Users Solidity address | -| INSUFFICIENT_GAS | Not enough gas was supplied to execute transaction | -| CONTRACT_SIZE_LIMIT_EXCEEDED | contract byte code size is over the limit | -| LOCAL_CALL_MODIFICATION_EXCEPTION | local execution (query) is requested for a function which changes state | -| CONTRACT_REVERT_EXECUTED | Contract REVERT OPCODE executed | -| CONTRACT_EXECUTION_EXCEPTION | For any contract execution related error not handled by specific error codes listed above. | -| INVALID_RECEIVING_NODE_ACCOUNT | In Query validation, account with +ve(amount) value should be Receiving node account, the receiver account should be only one account in the list | -| MISSING_QUERY_HEADER | Header is missing in Query request | -| ACCOUNT_UPDATE_FAILED | The update of the account failed | -| INVALID_KEY_ENCODING | Provided key encoding was not supported by the system | -| NULL_SOLIDITY_ADDRESS | null solidity address | -| CONTRACT_UPDATE_FAILED | update of the contract failed | -| INVALID_QUERY_HEADER | the query header is invalid | -| INVALID_FEE_SUBMITTED | Invalid fee submitted | -| INVALID_PAYER_SIGNATURE | Payer signature is invalid | -| KEY_NOT_PROVIDED | The keys were not provided in the request. | -| INVALID_EXPIRATION_TIME | Expiration time provided in the transaction was invalid. | -| NO_WACL_KEY | WriteAccess Control Keys are not provided for the file | -| FILE_CONTENT_EMPTY | The contents of file are provided as empty. | -| INVALID_ACCOUNT_AMOUNTS | The crypto transfer credit and debit do not sum equal to 0 | -| EMPTY_TRANSACTION_BODY | Transaction body provided is empty | -| INVALID_TRANSACTION_BODY | Invalid transaction body provided | -| INVALID_SIGNATURE_TYPE_MISMATCHING_KEY | the type of key (base ed25519 key, KeyList, or ThresholdKey) does not match the type of signature (base ed25519 signature, SignatureList, or ThresholdKeySignature) | -| INVALID_SIGNATURE_COUNT_MISMATCHING_KEY | the number of key (KeyList, or ThresholdKey) does not match that of signature (SignatureList, or ThresholdKeySignature). e.g. if a keyList has 3 base keys, then the corresponding signatureList should also have 3 base signatures. | -| EMPTY_CLAIM_BODY | the claim body is empty | -| EMPTY_CLAIM_HASH | the hash for the claim is empty | -| EMPTY_CLAIM_KEYS | the key list is empty | -| INVALID_CLAIM_HASH_SIZE | the size of the claim hash is not 48 bytes | -| EMPTY_QUERY_BODY | the query body is empty | -| EMPTY_CLAIM_QUERY | the crypto claim query is empty | -| CLAIM_NOT_FOUND | the crypto claim doesn't exists in the file system. It expired or was never persisted. | -| ACCOUNT_ID_DOES_NOT_EXIST | the account id passed has not yet been created. | -| CLAIM_ALREADY_EXISTS | the claim hash already exists | -| INVALID_FILE_WACL | File WACL keys are invalid | -| SERIALIZATION_FAILED | Serialization failure | -| TRANSACTION_OVERSIZE | The size of the Transaction is greater than transactionMaxBytes | -| TRANSACTION_TOO_MANY_LAYERS | The Transaction has more than 50 levels | -| CONTRACT_DELETED | Contract is marked as deleted | -| PLATFORM_NOT_ACTIVE | the platform node is either disconnected or lagging behind. | -| KEY_PREFIX_MISMATCH | one public key matches more than one prefixes on the signature map | -| PLATFORM_TRANSACTION_NOT_CREATED | transaction not created by platform due to either large backlog or message size exceeded transactionMaxBytes | -| INVALID_RENEWAL_PERIOD | auto renewal period is not a positive number of seconds | -| INVALID_PAYER_ACCOUNT_ID | the response code when a smart contract id is passed for a crypto API request | -| ACCOUNT_DELETED | the account has been marked as deleted | -| FILE_DELETED | the file has been marked as deleted | -| ACCOUNT_REPEATED_IN_ACCOUNT_AMOUNTS | same accounts repeated in the transfer account list | -| SETTING_NEGATIVE_ACCOUNT_BALANCE | attempting to set negative balance value for crypto account | -| OBTAINER_REQUIRED | when deleting smart contract that has crypto balance either transfer account or transfer smart contract is required | -| OBTAINER_SAME_CONTRACT_ID | when deleting smart contract that has crypto balance you can not use the same contract id as transferContractId as the one being deleted | -| OBTAINER_DOES_NOT_EXIST | transferAccountId or transferContractId specified for contract delete does not exist | -| MODIFYING_IMMUTABLE_CONTRACT | attempting to modify (update or delete a immutable smart contract, i.e. one created without a admin key) | -| FILE_SYSTEM_EXCEPTION | Unexpected exception thrown by file system functions | -| AUTORENEW_DURATION_NOT_IN_RANGE | the duration is not a subset of [MINIMUM_AUTORENEW_DURATION,MAXIMUM_AUTORENEW_DURATION] | -| ERROR_DECODING_BYTESTRING | Decoding the smart contract binary to a byte array failed. Check that the input is a valid hex string. | -| CONTRACT_FILE_EMPTY | File to create a smart contract was of length zero | -| CONTRACT_BYTECODE_EMPTY | Bytecode for smart contract is of length zero | -| INVALID_INITIAL_BALANCE | Attempt to set negative initial balance | -| INVALID_RECEIVE_RECORD_THRESHOLD | attempt to set negative receive record threshold | -| INVALID_SEND_RECORD_THRESHOLD | attempt to set negative send record threshold | -| ACCOUNT_IS_NOT_GENESIS_ACCOUNT | Special Account Operations should be performed by only Genesis account, return this code if it is not Genesis Account | -| PAYER_ACCOUNT_UNAUTHORIZED | The fee payer account doesn't have permission to submit such Transaction | -| INVALID_FREEZE_TRANSACTION_BODY | FreezeTransactionBody is invalid | -| FREEZE_TRANSACTION_BODY_NOT_FOUND | FreezeTransactionBody does not exist | -| TRANSFER_LIST_SIZE_LIMIT_EXCEEDED | Exceeded the number of accounts (both from and to) allowed for crypto transfer list | -| RESULT_SIZE_LIMIT_EXCEEDED | Smart contract result size greater than specified maxResultSize | -| NOT_SPECIAL_ACCOUNT | The payer account is not a special account(account 0.0.55) | -| CONTRACT_NEGATIVE_GAS | Negative gas was offered in smart contract call | -| CONTRACT_NEGATIVE_VALUE | Negative value / initial balance was specified in a smart contract call / create | -| INVALID_FEE_FILE | Failed to update fee file | -| INVALID_EXCHANGE_RATE_FILE | Failed to update exchange rate file | -| INSUFFICIENT_LOCAL_CALL_GAS | Payment tendered for contract local call cannot cover both the fee and the gas | -| ENTITY_NOT_ALLOWED_TO_DELETE | Entities with Entity ID below 1000 are not allowed to be deleted | -| AUTHORIZATION_FAILED | Violating one of these rules: 1) treasury account can update all entities below 0.0.1000, 2) account 0.0.50 can update all entities from 0.0.51 - 0.0.80, 3) Network Function Master Account A/c 0.0.50 - Update all Network Function accounts & perform all the Network Functions listed below, 4) Network Function Accounts: i) A/c 0.0.55 - Update Address Book files (0.0.101/102), ii) A/c 0.0.56 - Update Fee schedule (0.0.111), iii) A/c 0.0.57 - Update Exchange Rate (0.0.112). | -| FILE_UPLOADED_PROTO_INVALID | Fee Schedule Proto uploaded but not valid (append or update is required) | -| FILE_UPLOADED_PROTO_NOT_SAVED_TO_DISK | Fee Schedule Proto uploaded but not valid (append or update is required) | -| FEE_SCHEDULE_FILE_PART_UPLOADED | Fee Schedule Proto File Part uploaded | -| EXCHANGE_RATE_CHANGE_LIMIT_EXCEEDED | The change on Exchange Rate exceeds Exchange_Rate_Allowed_Percentage | -| MAX_CONTRACT_STORAGE_EXCEEDED | Contract permanent storage exceeded the currently allowable limit | -| TRANSFER_ACCOUNT_SAME_AS_DELETE_ACCOUNT | Transfer Account should not be same as Account to be deleted | -| TOTAL_LEDGER_BALANCE_INVALID | | -| EXPIRATION_REDUCTION_NOT_ALLOWED | The expiration date/time on a smart contract may not be reduced | -| MAX_GAS_LIMIT_EXCEEDED | Gas exceeded currently allowable gas limit per transaction | -| MAX_FILE_SIZE_EXCEEDED | File size exceeded the currently allowable limit | -| INVALID_TOPIC_ID | The Topic ID specified is not in the system. | -| INVALID_ADMIN_KEY | | -| INVALID_SUBMIT_KEY | | -| UNAUTHORIZED | An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey). | -| INVALID_TOPIC_MESSAGE | A ConsensusService message is empty. | -| INVALID_AUTORENEW_ACCOUNT | The autoRenewAccount specified is not a valid, active account. | -| AUTORENEW_ACCOUNT_NOT_ALLOWED | | -| TOPIC_EXPIRED | | - - -<a name="ResponseHeader.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## ResponseHeader.proto - -<a name="ResponseHeader"></a> - -### ResponseHeader - Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| nodeTransactionPrecheckCode | [ResponseCodeEnum](#ResponseCodeEnum) | Result of fee transaction precheck, saying it passed, or why it failed | | -| responseType | [ResponseType](#ResponseType) | The requested response is repeated back here, for convenience | | -| cost | | The fee that would be charged to get the requested information (if a cost was requested). Note: This cost only includes the query fee and does not include the transfer fee(which is required to execute the transfer transaction to debit the payer account and credit the node account with query fee) | | -| stateProof | | The state proof for this information (if a state proof was requested, and is available) | | - - -<a name="SmartContractService.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## SmartContractService.proto - -<a name="SmartContractService"></a> - -### SmartContractService - - -| RPC | Request | Response | Comments | -| --- | ------- | -------- | -------- | -| createContract | Transaction | TransactionResponse | Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse | -| updateContract | Transaction | TransactionResponse | Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse | -| contractCallMethod | Transaction | TransactionResponse | Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse | -| getContractInfo | Query | Response | Retrieves the contract information by submitting the query. The grpc server returns the Response | -| contractCallLocalMethod | Query | Response | Calls a smart contract by submitting the query. The grpc server returns the Response | -| ContractGetBytecode | Query | Response | Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response | -| getBySolidityID | Query | Response | Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response | -| getTxRecordByContractID | Query | Response | Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response | -| deleteContract | Transaction | TransactionResponse | Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse | -| systemDelete | Transaction | TransactionResponse | Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | -| systemUndelete | Transaction | TransactionResponse | UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | - - -<a name="SystemDelete.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## SystemDelete.proto - -<a name="SystemDeleteTransactionBody"></a> - -### SystemDeleteTransactionBody - Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| id | oneof | | | -| | fileID | [FileID](#FileID) | The file ID of the file to delete, in the format used in transactions | | -| | contractID | [ContractID](#ContractID) | The contract ID instance to delete, in the format used in transactions | | -| expirationTime | [TimestampSeconds](#TimestampSeconds) | The timestamp in seconds at which the "deleted" file should truly be permanently deleted | | - - -<a name="SystemUndelete.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## SystemUndelete.proto - -<a name="SystemUndeleteTransactionBody"></a> - -### SystemUndeleteTransactionBody - Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| id | oneof | | | -| | fileID | [FileID](#FileID) | The file ID to undelete, in the format used in transactions | | -| | contractID | [ContractID](#ContractID) | The contract ID instance to undelete, in the format used in transactions | | - - -<a name="Timestamp.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Timestamp.proto - -<a name="Timestamp"></a> - -### Timestamp - 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) - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| seconds | | Number of complete seconds since the start of the epoch | | -| nanos | | Number of nanoseconds since the start of the last second | | - - -<a name="TimestampSeconds"></a> - -### TimestampSeconds - An exact date and time, with a resolution of one second (no nanoseconds). - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| seconds | | Number of complete seconds since the start of the epoch | | - - -<a name="Transaction.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## Transaction.proto - -<a name="Transaction"></a> - -### Transaction - 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. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| bodyData | oneof | | | -| | body | [TransactionBody](#TransactionBody) | the body of the transaction, which needs to be signed | | -| | bodyBytes | | TransactionBody serialized into bytes , which needs to be signed | | -| sigs | [SignatureList](#SignatureList) | The signatures on the body, to authorize the transaction; deprecated and to be succeeded by SignatureMap field | | -| sigMap | [SignatureMap](#SignatureMap) | The signatures on the body with the new format, to authorize the transaction | | - - -<a name="TransactionBody.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionBody.proto - -<a name="TransactionBody"></a> - -### TransactionBody - A single transaction. All transaction types are possible here. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| transactionID | [TransactionID](#TransactionID) | 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 | | -| nodeAccountID | [AccountID](#AccountID) | The account of the node that submits the client's transaction to the network | | -| transactionFee | | The maximum transaction fee the client is willing to pay, which is split between the network and the node | | -| transactionValidDuration | [Duration](#Duration) | The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration | | -| generateRecord | | Should a record of this transaction be generated? (A receipt is always generated, but the record is optional) | | -| memo | | Any notes or descriptions that should be put into the record (max length 100) | | -| data | oneof | | | -| | contractCall | [ContractCallTransactionBody](#ContractCallTransactionBody) | Contains the call a function of a contract instance | | -| | contractCreateInstance | [ContractCreateTransactionBody](#ContractCreateTransactionBody) | Contains the create data a contract instance | | -| | contractUpdateInstance | [ContractUpdateTransactionBody](#ContractUpdateTransactionBody) | Contains contract modify info such as expiration date for a contract instance | | -| | contractDeleteInstance | [ContractDeleteTransactionBody](#ContractDeleteTransactionBody) | Delete contract and transfer remaining balance into specified account | | -| | cryptoAddClaim | [CryptoAddClaimTransactionBody](#CryptoAddClaimTransactionBody) | Attach a new claim to an account | | -| | cryptoCreateAccount | [CryptoCreateTransactionBody](#CryptoCreateTransactionBody) | Create a new cryptocurrency account | | -| | cryptoDelete | [CryptoDeleteTransactionBody](#CryptoDeleteTransactionBody) | Delete a cryptocurrency account (mark as deleted, and transfer hbars out) | | -| | cryptoDeleteClaim | [CryptoDeleteClaimTransactionBody](#CryptoDeleteClaimTransactionBody) | Remove a claim from an account | | -| | cryptoTransfer | [CryptoTransferTransactionBody](#CryptoTransferTransactionBody) | Transfer amount between accounts | | -| | cryptoUpdateAccount | [CryptoUpdateTransactionBody](#CryptoUpdateTransactionBody) | Modify information such as the expiration date for an account | | -| | fileAppend | [FileAppendTransactionBody](#FileAppendTransactionBody) | Add bytes to the end of the contents of a file | | -| | fileCreate | [FileCreateTransactionBody](#FileCreateTransactionBody) | Create a new file | | -| | fileDelete | [FileDeleteTransactionBody](#FileDeleteTransactionBody) | Delete a file (remove contents and mark as deleted until it expires) | | -| | fileUpdate | [FileUpdateTransactionBody](#FileUpdateTransactionBody) | Modify information such as the expiration date for a file | | -| | systemDelete | [SystemDeleteTransactionBody](#SystemDeleteTransactionBody) | Hedera multisig system deletes a file or smart contract | | -| | systemUndelete | [SystemUndeleteTransactionBody](#SystemUndeleteTransactionBody) | To undelete an entity deleted by SystemDelete | | -| | freeze | [FreezeTransactionBody](#FreezeTransactionBody) | Freeze the nodes | | -| | consensusCreateTopic | [ConsensusCreateTopicTransactionBody](#ConsensusCreateTopicTransactionBody) | | | -| | consensusUpdateTopic | [ConsensusUpdateTopicTransactionBody](#ConsensusUpdateTopicTransactionBody) | | | -| | consensusDeleteTopic | [ConsensusDeleteTopicTransactionBody](#ConsensusDeleteTopicTransactionBody) | | | -| | consensusSubmitMessage | [ConsensusSubmitMessageTransactionBody](#ConsensusSubmitMessageTransactionBody) | | | - - -<a name="TransactionGetFastRecord.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionGetFastRecord.proto - -<a name="TransactionGetFastRecordQuery"></a> - -### TransactionGetFastRecordQuery - Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| transactionID | [TransactionID](#TransactionID) | The ID of the transaction for which the record is requested. | | - - -<a name="TransactionGetFastRecordResponse"></a> - -### TransactionGetFastRecordResponse - Response when the client sends the node TransactionGetFastRecordQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| transactionRecord | [TransactionRecord](#TransactionRecord) | The requested transaction records | | - - -<a name="TransactionGetReceipt.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionGetReceipt.proto - -<a name="TransactionGetReceiptQuery"></a> - -### TransactionGetReceiptQuery - Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| transactionID | [TransactionID](#TransactionID) | The ID of the transaction for which the receipt is requested. | | - - -<a name="TransactionGetReceiptResponse"></a> - -### TransactionGetReceiptResponse - Response when the client sends the node TransactionGetReceiptQuery. If it created a new entity (account, file, or smart contract instance) then one of the three ID fields will be filled in with the ID of the new entity. Sometimes a single transaction will create more than one new entity, such as when a new contract instance is created, and this also creates the new account that it owned by that instance. No State proof is available for this response - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither | | -| receipt | [TransactionReceipt](#TransactionReceipt) | The receipt, indicating it reached consensus (and whether it succeeded or failed) or is currently unknown (because it hasn't reached consensus yet, or the transaction has expired already), and including the ID of any new account/file/instance created by that transaction. | | - - -<a name="TransactionGetRecord.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionGetRecord.proto - -<a name="TransactionGetRecordQuery"></a> - -### TransactionGetRecordQuery - Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested (cost, state proof, both, or neither). | | -| transactionID | [TransactionID](#TransactionID) | The ID of the transaction for which the record is requested. | | - - -<a name="TransactionGetRecordResponse"></a> - -### TransactionGetRecordResponse - Response when the client sends the node TransactionGetRecordQuery - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither. | | -| transactionRecord | [TransactionRecord](#TransactionRecord) | The requested record | | - - -<a name="TransactionReceipt.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionReceipt.proto - -<a name="TransactionReceipt"></a> - -### TransactionReceipt - The consensus result for a transaction, which might not be currently known, or may succeed or fail. - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| status | [ResponseCodeEnum](#ResponseCodeEnum) | whether the transaction succeeded or failed (or is unknown) | | -| accountID | [AccountID](#AccountID) | The account ID, if a new account was created | | -| fileID | [FileID](#FileID) | The file ID, if a new file was created | | -| contractID | [ContractID](#ContractID) | The contract ID, if a new smart contract instance was created | | -| exchangeRate | [ExchangeRateSet](#ExchangeRateSet) | exchange rate set of Hbar to cents (USD) | | -| topicID | [TopicID](#TopicID) | TopicID of a newly created consensus service topic | | -| topicSequenceNumber | | | | -| topicRunningHash | | | | - - -<a name="TransactionRecord.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionRecord.proto - -<a name="TransactionRecord"></a> - -### TransactionRecord - Response when the client sends the node TransactionGetRecordResponse - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| receipt | [TransactionReceipt](#TransactionReceipt) | The status (reach consensus, or failed, or is unknown) and the ID of any new account/file/instance created. | | -| transactionHash | | The hash of the Transaction that executed (not the hash of any Transaction that failed for having a duplicate TransactionID) | | -| consensusTimestamp | [Timestamp](#Timestamp) | The consensus timestamp (or null if didn't reach consensus yet) | | -| transactionID | [TransactionID](#TransactionID) | The ID of the transaction this record represents | | -| memo | | The memo that was submitted as part of the transaction (max 100 bytes) | | -| transactionFee | | The actual transaction fee charged, not the original transactionFee value from TransactionBody | | -| body | oneof | | | -| | contractCallResult | [ContractFunctionResult](#ContractFunctionResult) | Record of the value returned by the smart contract function (if it completed and didn't fail) from ContractCallTransaction | | -| | contractCreateResult | [ContractFunctionResult](#ContractFunctionResult) | Record of the value returned by the smart contract constructor (if it completed and didn't fail) from ContractCreateTransaction | | -| transferList | [TransferList](#TransferList) | All hbar transfers as a result of this transaction, such as fees, or transfers performed by the transaction, or by a smart contract it calls, or by the creation of threshold records that it triggers. | | - - -<a name="TransactionResponse.proto"></a> -<p align="right"><a href="#top">Top</a></p> - -## TransactionResponse.proto - -<a name="TransactionResponse"></a> - -### TransactionResponse - When the client sends the node a transaction of any kind, the node replies with this, which simply says that the transaction passed the precheck (so the node will submit it to the network) or it failed (so it won't). If the fee offered was insufficient, this will also contain the amount of the required fee. To learn the consensus result, the client should later obtain a receipt (free), or can buy a more detailed record (not free). - -| Field | Type | Description | | -| ----- | ---- | ----------- | - | -| nodeTransactionPrecheckCode | [ResponseCodeEnum](#ResponseCodeEnum) | The response code that indicates the current status of the transaction. | | -| cost | | If the response code was INSUFFICIENT_TX_FEE, the actual transaction fee that would be required to execute the transaction. | | - diff --git a/docs/NotNestedDoc.html b/docs/NotNestedDoc.html index 6eb6da81..1f1cb1f5 100644 --- a/docs/NotNestedDoc.html +++ b/docs/NotNestedDoc.html @@ -32,7 +32,7 @@ <li> <a href="#RealmID"><span class="badge">M</span>RealmID</a></li> <li> -<a href="#ServicesConfigurationLis"><span class="badge">M</span>ServicesConfigurationLis</a></li> +<a href="#ServicesConfigurationList"><span class="badge">M</span>ServicesConfigurationList</a></li> <li> <a href="#Setting"><span class="badge">M</span>Setting</a></li> <li> @@ -58,12 +58,20 @@ </ul> <a href=#ConsensusCreateTopic.proto>ConsensusCreateTopic.proto</a> <ul> +<li> +<a href="#ConsensusCreateTopicTransactionBody"><span class="badge">M</span>ConsensusCreateTopicTransactionBody</a></li> </ul> <a href=#ConsensusDeleteTopic.proto>ConsensusDeleteTopic.proto</a> <ul> +<li> +<a href="#ConsensusDeleteTopicTransactionBody"><span class="badge">M</span>ConsensusDeleteTopicTransactionBody</a></li> </ul> <a href=#ConsensusGetTopicInfo.proto>ConsensusGetTopicInfo.proto</a> <ul> +<li> +<a href="#ConsensusGetTopicInfoQuery"><span class="badge">M</span>ConsensusGetTopicInfoQuery</a></li> +<li> +<a href="#ConsensusGetTopicInfoResponse"><span class="badge">M</span>ConsensusGetTopicInfoResponse</a></li> </ul> <a href=#ConsensusService.proto>ConsensusService.proto</a> <ul> @@ -77,9 +85,13 @@ </ul> <a href=#ConsensusTopicInfo.proto>ConsensusTopicInfo.proto</a> <ul> +<li> +<a href="#ConsensusTopicInfo"><span class="badge">M</span>ConsensusTopicInfo</a></li> </ul> <a href=#ConsensusUpdateTopic.proto>ConsensusUpdateTopic.proto</a> <ul> +<li> +<a href="#ConsensusUpdateTopicTransactionBody"><span class="badge">M</span>ConsensusUpdateTopicTransactionBody</a></li> </ul> <a href=#ContractCall.proto>ContractCall.proto</a> <ul> @@ -402,6 +414,7 @@ <H2 id="BasicTypes.proto">BasicTypes.proto</H2> <a href="#title">Top</a> </div> +<P> 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.</P> <H3 id="AccountID"><span class="BigBadge">Message</span>AccountID</H3> <P> The ID for an a cryptocurrency account </P> <table class="field-table"> @@ -886,7 +899,7 @@ <H3 id="HederaFunctionality"><span class="BigBadge">Enum</span>HederaFunctionali </TABLE> <H3 id="Key"><span class="BigBadge">Message</span>Key</H3> -<P> 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.</P> +<P> 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.</P> <table class="field-table"> <thead> <TR> @@ -1059,7 +1072,7 @@ <H3 id="RealmID"><span class="BigBadge">Message</span>RealmID</H3> <tbody> </TABLE> -<H3 id="ServicesConfigurationLis"><span class="BigBadge">Message</span>ServicesConfigurationLis</H3> +<H3 id="ServicesConfigurationList"><span class="BigBadge">Message</span>ServicesConfigurationList</H3> <P></P> <table class="field-table"> <thead> @@ -1112,7 +1125,7 @@ <H3 id="Setting"><span class="BigBadge">Message</span>Setting</H3> </TABLE> <H3 id="ShardID"><span class="BigBadge">Message</span>ShardID</H3> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -1132,7 +1145,7 @@ <H3 id="ShardID"><span class="BigBadge">Message</span>ShardID</H3> </TABLE> <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> -<P> 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.</P> +<P> 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -1208,7 +1221,7 @@ <H3 id="Signature"><span class="BigBadge">Message</span>Signature</H3> </TABLE> <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> -<P> The signatures corresponding to a KeyList of the same length.</P> +<P> The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -1234,7 +1247,7 @@ <H3 id="SignatureList"><span class="BigBadge">Message</span>SignatureList</H3> </TABLE> <H3 id="SignatureMap"><span class="BigBadge">Message</span>SignatureMap</H3> -<P> A set of signatures corresponding to every unique public key used to sign a given transaction.</P> +<P> A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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.</P> <table class="field-table"> <thead> <TR> @@ -1254,7 +1267,7 @@ <H3 id="SignatureMap"><span class="BigBadge">Message</span>SignatureMap</H3> </TABLE> <H3 id="SignaturePair"><span class="BigBadge">Message</span>SignaturePair</H3> -<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.</P> +<P> The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign.</P> <table class="field-table"> <thead> <TR> @@ -1344,7 +1357,7 @@ <H3 id="ThresholdKey"><span class="BigBadge">Message</span>ThresholdKey</H3> </TABLE> <H3 id="ThresholdSignature"><span class="BigBadge">Message</span>ThresholdSignature</H3> -<P> 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.</P> +<P> 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages.</P> <table class="field-table"> <thead> <TR> @@ -1457,18 +1470,144 @@ <H3 id="TransactionID"><span class="BigBadge">Message</span>TransactionID</H3> <H2 id="ConsensusCreateTopic.proto">ConsensusCreateTopic.proto</H2> <a href="#title">Top</a> </div> +<P> See [ConsensusService.createTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusCreateTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusCreateTopicTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed.</P></TD> +</TR> + +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed).</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required.</P></TD> +</TR> + +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction.</P></TD> +</TR> + +<tbody> +</TABLE> + <div class="file-heading"> <H2 id="ConsensusDeleteTopic.proto">ConsensusDeleteTopic.proto</H2> <a href="#title">Top</a> </div> +<P> See [ConsensusService.deleteTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusDeleteTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusDeleteTopicTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<tbody> +</TABLE> + <div class="file-heading"> <H2 id="ConsensusGetTopicInfo.proto">ConsensusGetTopicInfo.proto</H2> <a href="#title">Top</a> </div> +<P> See [ConsensusService.getTopicInfo()](#proto.ConsensusService)</P> +<H3 id="ConsensusGetTopicInfoQuery"><span class="BigBadge">Message</span>ConsensusGetTopicInfoQuery</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#QueryHeader">QueryHeader</a></TD> +<TD><P> Standard info sent from client to node, including the signed payment, and what kind of response is requested<BR>(cost, state proof, both, or neither).</P></TD> +</TR> + +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic to retrieve info about (the parameters and running state of).</P></TD> +</TR> + +<tbody> +</TABLE> + +<H3 id="ConsensusGetTopicInfoResponse"><span class="BigBadge">Message</span>ConsensusGetTopicInfoResponse</H3> +<P> Retrieve the parameters of and state of a consensus topic.</P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>header</TD> +<TD><a href="#ResponseHeader">ResponseHeader</a></TD> +<TD><P> Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither.</P></TD> +</TR> + +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P>Topic identifier.</P></TD> +</TR> + +<TR> +<TD>topicInfo</TD> +<TD><a href="#ConsensusTopicInfo">ConsensusTopicInfo</a></TD> +<TD><P>Current state of the topic</P></TD> +</TR> + +<tbody> +</TABLE> + <div class="file-heading"> <H2 id="ConsensusService.proto">ConsensusService.proto</H2> <a href="#title">Top</a> </div> +<P> The Consensus Service provides the ability for Hedera Hashgraph to provide aBFT consensus as to the order and<BR>validity of messages submitted to a topic, as well as a consensus timestamp for those messages.<BR>Automatic renewal can be configured via an autoRenewAccount.<BR>Any time an autoRenewAccount is added to a topic, that createTopic/updateTopic transaction must be signed by<BR>the autoRenewAccount.<BR>The autoRenewPeriod on an account must currently be set a value in createTopic between MIN_AUTORENEW_PERIOD (6999999<BR>seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds). During creation this sets the initial expirationTime of the<BR>topic (see more below).<BR>If no adminKey is on a topic, there may not be an autoRenewAccount on the topic, deleteTopic is not allowed,<BR>and the only change allowed via an updateTopic is to extend the expirationTime.<BR>If an adminKey is on a topic, every updateTopic and deleteTopic transaction must be signed by the adminKey, except<BR>for updateTopics which only extend the topic's expirationTime (no adminKey authorization required).<BR>If an updateTopic modifies the adminKey of a topic, the transaction signatures on the updateTopic must fulfill both<BR>the pre-update and post-update adminKey signature requirements.<BR>Mirrornet ConsensusService may be used to subscribe to changes on the topic, including changes to the topic<BR>definition and the consensus ordering and timestamp of submitted messages.<BR>Until autoRenew functionality is supported by HAPI, the topic will not expire, the autoRenewAccount will not be<BR>charged, and the topic will not automatically be deleted.<BR>Once autoRenew functionality is supported by HAPI:<BR>1. Once the expirationTime is encountered, if an autoRenewAccount is configured on the topic, the account will be<BR>charged automatically at the expirationTime, to extend the expirationTime of the topic up to the topic's<BR>autoRenewPeriod (or as much extension as the account's balance will supply).<BR>2. If the topic expires and is not automatically renewed, the topic will enter the EXPIRED state. All transactions<BR>on the topic will fail with TOPIC_EXPIRED, except an updateTopic() call that modifies only the expirationTime.<BR>getTopicInfo() will succeed. This state will be available for a AUTORENEW_GRACE_PERIOD grace period (7 days).<BR>3. After the grace period, if the topic's expirationTime is not extended, the topic will be automatically<BR>deleted and no transactions or queries on the topic will succeed after that point.</P> <H3 id="ConsensusService"><span class="BigBadge">Service</span>ConsensusService</H3> <P></P> <table class="field-table"> @@ -1482,23 +1621,23 @@ <H3 id="ConsensusService"><span class="BigBadge">Service</span>ConsensusService< </thead> <tbody> <TR> -<TD>createTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> +<TD>createTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Create a topic to be used for consensus.<BR>If an autoRenewAccount is specified, that account must also sign this transaction.<BR>If an adminKey is specified, the adminKey must sign the transaction.<BR>On success, the resulting TransactionReceipt contains the newly created TopicId.<BR>Request is [ConsensusCreateTopicTransactionBody](#proto.ConsensusCreateTopicTransactionBody)</P></TD> </TR> <TR> -<TD>updateTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> +<TD>updateTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Update a topic.<BR>If there is no adminKey, the only authorized update (available to anyone) is to extend the expirationTime.<BR>Otherwise transaction must be signed by the adminKey.<BR>If an adminKey is updated, the transaction must be signed by the pre-update adminKey and post-update adminKey.<BR>If a new autoRenewAccount is specified (not just being removed), that account must also sign the transaction.<BR>Request is [ConsensusUpdateTopicTransactionBody](#proto.ConsensusUpdateTopicTransactionBody)</P></TD> </TR> <TR> -<TD>deleteTopic </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> +<TD>deleteTopic </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Delete a topic. No more transactions or queries on the topic (via HAPI) will succeed.<BR>If an adminKey is set, this transaction must be signed by that key.<BR>If there is no adminKey, this transaction will fail UNAUTHORIZED.<BR>Request is [ConsensusDeleteTopicTransactionBody](#proto.ConsensusDeleteTopicTransactionBody)</P></TD> </TR> <TR> -<TD>getTopicInfo </TD><TD>Query</TD><TD>Response);</P></TD> +<TD>getTopicInfo </TD><TD>Query</TD><TD>Response</TD><TD><P> Retrieve the latest state of a topic. This method is unrestricted and allowed on any topic by any payer account.<BR>Deleted accounts will not be returned.<BR>Request is [ConsensusGetTopicInfoQuery](#proto.ConsensusGetTopicInfoQuery)<BR>Response is [ConsensusGetTopicInfoResponse](#proto.ConsensusGetTopicInfoResponse)</P></TD> </TR> <TR> -<TD>submitMessage </TD><TD>Transaction</TD><TD>TransactionResponse);</P></TD> +<TD>submitMessage </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P> Submit a message for consensus.<BR>Valid and authorized messages on valid topics will be ordered by the consensus service, gossipped to the<BR>mirror net, and published (in order) to all subscribers (from the mirror net) on this topic.<BR>The submitKey (if any) must sign this transaction.<BR>On success, the resulting TransactionReceipt contains the topic's updated topicSequenceNumber and<BR>topicRunningHash.<BR>Request is [ConsensusSubmitMessageTransactionBody](#proto.ConsensusSubmitMessageTransactionBody)</P></TD> </TR> <tbody> @@ -1538,16 +1677,137 @@ <H3 id="ConsensusSubmitMessageTransactionBody"><span class="BigBadge">Message</s <H2 id="ConsensusTopicInfo.proto">ConsensusTopicInfo.proto</H2> <a href="#title">Top</a> </div> +<P> Current state of a topic.</P> +<H3 id="ConsensusTopicInfo"><span class="BigBadge">Message</span>ConsensusTopicInfo</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>memo</TD> +<TD>string</TD> +<TD><P>Short publicly visible memo about the topic. No guarantee of uniqueness.</P></TD> +</TR> + +<TR> +<TD>runningHash</TD> +<TD>bytes</TD> +<TD><P> SHA-384 running hash <previousRunningHash, topicId, consensusTimestamp, sequenceNumber, message></P></TD> +</TR> + +<TR> +<TD>sequenceNumber</TD> +<TD>uint64</TD> +<TD><P> Sequence number (starting at 1 for the first submitMessage) of messages on the topic.</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which submitMessage calls will no longer succeed on the topic<BR>and the topic will expire and after AUTORENEW_GRACE_PERIOD be automatically deleted.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for update/delete of the topic. Null if there is no key.</P></TD> +</TR> + +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P>Access control for ConsensusService.submitMessage. Null if there is no key.</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P>Null if there is no autoRenewAccount.</P></TD> +</TR> + +<tbody> +</TABLE> + <div class="file-heading"> <H2 id="ConsensusUpdateTopic.proto">ConsensusUpdateTopic.proto</H2> <a href="#title">Top</a> </div> +<P> All fields left null will not be updated.<BR>See [ConsensusService.updateTopic()](#proto.ConsensusService)</P> +<H3 id="ConsensusUpdateTopicTransactionBody"><span class="BigBadge">Message</span>ConsensusUpdateTopicTransactionBody</H3> +<P></P> +<table class="field-table"> +<thead> +<TR> +<TD>Field</TD> +<TD>Type</TD> +<TD>Description</TD> +</TR> +</thead> +<tbody> +<TR> +<TD>topicID</TD> +<TD><a href="#TopicID">TopicID</a></TD> +<TD><P></P></TD> +</TR> + +<TR> +<TD>memo</TD> +<TD><a href="#google.protobuf.StringValue">google.protobuf.StringValue</a></TD> +<TD><P> Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update".</P></TD> +</TR> + +<TR> +<TD>expirationTime</TD> +<TD><a href="#Timestamp">Timestamp</a></TD> +<TD><P> Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD>adminKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared.</P></TD> +</TR> + +<TR> +<TD>submitKey</TD> +<TD><a href="#Key">Key</a></TD> +<TD><P> Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared.</P></TD> +</TR> + +<TR> +<TD>autoRenewPeriod</TD> +<TD><a href="#Duration">Duration</a></TD> +<TD><P> The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change.</P></TD> +</TR> + +<TR> +<TD>autoRenewAccount</TD> +<TD><a href="#AccountID">AccountID</a></TD> +<TD><P> Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change.</P></TD> +</TR> + +<tbody> +</TABLE> + <div class="file-heading"> <H2 id="ContractCall.proto">ContractCall.proto</H2> <a href="#title">Top</a> </div> +<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.<BR>If this function stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee.</P> <H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>ContractCallTransactionBody</H3> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -1588,8 +1848,9 @@ <H3 id="ContractCallTransactionBody"><span class="BigBadge">Message</span>Contra <H2 id="ContractCallLocal.proto">ContractCallLocal.proto</H2> <a href="#title">Top</a> </div> +<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> <H3 id="ContractCallLocalQuery"><span class="BigBadge">Message</span>ContractCallLocalQuery</H3> -<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.</P> +<P> Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.<BR>This is performed locally on the particular node that the client is communicating with. It cannot change the state of the contract instance (and so, cannot spend anything from the instance's cryptocurrency account). It will not have a consensus timestamp. It cannot generate a record or a receipt. The response will contain the output returned by the function call. This is useful for calling getter functions, which purely read the state and don't change it. It is faster and cheaper than a normal call, because it is purely local to a single node.</P> <table class="field-table"> <thead> <TR> @@ -1709,7 +1970,7 @@ <H3 id="ContractFunctionResult"><span class="BigBadge">Message</span>ContractFun </TABLE> <H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H3> -<P> The log information for an event returned by a smart contract function call. One function call may return several such events. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -1750,8 +2011,9 @@ <H3 id="ContractLoginfo"><span class="BigBadge">Message</span>ContractLoginfo</H <H2 id="ContractCreate.proto">ContractCreate.proto</H2> <a href="#title">Top</a> </div> +<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.<BR>The instance will exist for autoRenewPeriod seconds. When that is reached, it will renew itself for another autoRenewPeriod seconds by charging its associated cryptocurrency account (which it creates here). If it has insufficient cryptocurrency to extend that long, it will extend as long as it can. If its balance is zero, the instance will be deleted.<BR>A smart contract instance normally enforces rules, so "the code is law". For example, an ERC-20 contract prevents a transfer from being undone without a signature by the recipient of the transfer. This is always enforced if the contract instance was created with the adminKeys being null. But for some uses, it might be desirable to create something like an ERC-20 contract that has a specific group of trusted individuals who can act as a "supreme court" with the ability to override the normal operation, when a sufficient number of them agree to do so. If adminKeys is not null, then they can sign a transaction that can change the state of the smart contract in arbitrary ways, such as to reverse a transaction that violates some standard of behavior that is not covered by the code itself. The admin keys can also be used to change the autoRenewPeriod, and change the adminKeys field itself. The API currently does not implement this ability. But it does allow the adminKeys field to be set and queried, and will in the future implement such admin abilities for any instance that has a non-null adminKeys.<BR>If this constructor stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee.<BR>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.<BR>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.<BR>The optional memo field can contain a string whose length is up to 100 bytes. That is the size after Unicode NFD then UTF-8 conversion. This field can be used to describe the smart contract. It could also be used for other purposes. One recommended purpose is to hold a hexadecimal string that is the SHA-384 hash of a PDF file containing a human-readable legal contract. Then, if the admin keys are the public keys of human arbitrators, they can use that legal document to guide their decisions during a binding arbitration tribunal, convened to consider any changes to the smart contract in the future. The memo field can only be changed using the admin keys. If there are no admin keys, then it cannot be changed after the smart contract is created.</P> <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>ContractCreateTransactionBody</H3> -<P> Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -1834,8 +2096,9 @@ <H3 id="ContractCreateTransactionBody"><span class="BigBadge">Message</span>Cont <H2 id="ContractDelete.proto">ContractDelete.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>ContractDeleteTransactionBody</H3> <P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>ContractDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -1890,8 +2153,9 @@ <H3 id="ContractDeleteTransactionBody"><span class="BigBadge">Message</span>Cont <H2 id="ContractGetBytecode.proto">ContractGetBytecode.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractGetBytecodeQuery</H3> <P> Get the bytecode for a smart contract instance </P> +<H3 id="ContractGetBytecodeQuery"><span class="BigBadge">Message</span>ContractGetBytecodeQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -1946,8 +2210,9 @@ <H3 id="ContractGetBytecodeResponse"><span class="BigBadge">Message</span>Contra <H2 id="ContractGetInfo.proto">ContractGetInfo.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetInfoQuery</H3> <P> Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. </P> +<H3 id="ContractGetInfoQuery"><span class="BigBadge">Message</span>ContractGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -1999,7 +2264,7 @@ <H3 id="ContractGetInfoResponse"><span class="BigBadge">Message</span>ContractGe </TABLE> <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</span>ContractGetInfoResponse.ContractInfo</H3> -<P> Response when the client sends the node ContractGetInfoQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -2070,8 +2335,9 @@ <H3 id="ContractGetInfoResponse.ContractInfo"><span class="BigBadge">Message</sp <H2 id="ContractGetRecords.proto">ContractGetRecords.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGetRecordsQuery</H3> <P> Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. </P> +<H3 id="ContractGetRecordsQuery"><span class="BigBadge">Message</span>ContractGetRecordsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2132,8 +2398,9 @@ <H3 id="ContractGetRecordsResponse"><span class="BigBadge">Message</span>Contrac <H2 id="ContractUpdate.proto">ContractUpdate.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>ContractUpdateTransactionBody</H3> <P> Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. </P> +<H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>ContractUpdateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2192,8 +2459,9 @@ <H3 id="ContractUpdateTransactionBody"><span class="BigBadge">Message</span>Cont <H2 id="CryptoAddClaim.proto">CryptoAddClaim.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Claim"><span class="BigBadge">Message</span>Claim</H3> <P> A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. </P> +<H3 id="Claim"><span class="BigBadge">Message</span>Claim</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2231,7 +2499,7 @@ <H3 id="Claim"><span class="BigBadge">Message</span>Claim</H3> </TABLE> <H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>CryptoAddClaimTransactionBody</H3> -<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.</P> +<P> Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added.</P> <table class="field-table"> <thead> <TR> @@ -2254,8 +2522,9 @@ <H3 id="CryptoAddClaimTransactionBody"><span class="BigBadge">Message</span>Cryp <H2 id="CryptoCreate.proto">CryptoCreate.proto</H2> <a href="#title">Top</a> </div> +<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.<BR>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.<BR>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.</P> <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>CryptoCreateTransactionBody</H3> -<P> Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -2332,8 +2601,9 @@ <H3 id="CryptoCreateTransactionBody"><span class="BigBadge">Message</span>Crypto <H2 id="CryptoDelete.proto">CryptoDelete.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteTransactionBody</H3> <P> Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. </P> +<H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2362,8 +2632,9 @@ <H3 id="CryptoDeleteTransactionBody"><span class="BigBadge">Message</span>Crypto <H2 id="CryptoDeleteClaim.proto">CryptoDeleteClaim.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteClaimTransactionBody</H3> <P> Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. </P> +<H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>CryptoDeleteClaimTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2392,8 +2663,9 @@ <H3 id="CryptoDeleteClaimTransactionBody"><span class="BigBadge">Message</span>C <H2 id="CryptoGetAccountBalance.proto">CryptoGetAccountBalance.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>CryptoGetAccountBalanceQuery</H3> <P> Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. </P> +<H3 id="CryptoGetAccountBalanceQuery"><span class="BigBadge">Message</span>CryptoGetAccountBalanceQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2480,8 +2752,9 @@ <H3 id="CryptoGetAccountBalanceResponse"><span class="BigBadge">Message</span>Cr <H2 id="CryptoGetAccountRecords.proto">CryptoGetAccountRecords.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>CryptoGetAccountRecordsQuery</H3> <P> Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. </P> +<H3 id="CryptoGetAccountRecordsQuery"><span class="BigBadge">Message</span>CryptoGetAccountRecordsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2542,8 +2815,9 @@ <H3 id="CryptoGetAccountRecordsResponse"><span class="BigBadge">Message</span>Cr <H2 id="CryptoGetClaim.proto">CryptoGetClaim.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaimQuery</H3> <P> Get a single claim attached to an account, or return null if it does not exist. </P> +<H3 id="CryptoGetClaimQuery"><span class="BigBadge">Message</span>CryptoGetClaimQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2604,8 +2878,9 @@ <H3 id="CryptoGetClaimResponse"><span class="BigBadge">Message</span>CryptoGetCl <H2 id="CryptoGetInfo.proto">CryptoGetInfo.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQuery</H3> <P> Get all the information about an account, including the balance. This does not get the list of account records. </P> +<H3 id="CryptoGetInfoQuery"><span class="BigBadge">Message</span>CryptoGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -2657,7 +2932,7 @@ <H3 id="CryptoGetInfoResponse"><span class="BigBadge">Message</span>CryptoGetInf </TABLE> <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span>CryptoGetInfoResponse.AccountInfo</H3> -<P> Response when the client sends the node CryptoGetInfoQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -2752,6 +3027,7 @@ <H3 id="CryptoGetInfoResponse.AccountInfo"><span class="BigBadge">Message</span> <H2 id="CryptoGetStakers.proto">CryptoGetStakers.proto</H2> <a href="#title">Top</a> </div> +<P> Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. </P> <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H3> <P> all of the accounts proxy staking to a given account, and the amounts proxy staked </P> <table class="field-table"> @@ -2779,7 +3055,7 @@ <H3 id="AllProxyStakers"><span class="BigBadge">Message</span>AllProxyStakers</H </TABLE> <H3 id="CryptoGetStakersQuery"><span class="BigBadge">Message</span>CryptoGetStakersQuery</H3> -<P> Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -2860,6 +3136,7 @@ <H3 id="ProxyStaker"><span class="BigBadge">Message</span>ProxyStaker</H3> <H2 id="CryptoService.proto">CryptoService.proto</H2> <a href="#title">Top</a> </div> +<P> The request and responses for different crypto services. </P> <H3 id="CryptoService"><span class="BigBadge">Service</span>CryptoService</H3> <P></P> <table class="field-table"> @@ -2873,59 +3150,59 @@ <H3 id="CryptoService"><span class="BigBadge">Service</span>CryptoService</H3> </thead> <tbody> <TR> -<TD>createAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>createAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>updateAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates an account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>updateAccount </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates an account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>cryptoTransfer </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>cryptoTransfer </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>cryptoDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>cryptoDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>addClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>addClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>deleteClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>deleteClaim </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>getClaim </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the claim for an account by submitting the query.</P></TD> +<TD>getClaim </TD><TD>Query</TD><TD>Response</TD>Retrieves the claim for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>getAccountRecords </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the record(fetch by AccountID ID) for an account by submitting the query.</P></TD> +<TD>getAccountRecords </TD><TD>Query</TD><TD>Response</TD>Retrieves the record(fetch by AccountID ID) for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>cryptoGetBalance </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the balance for an account by submitting the query.</P></TD> +<TD>cryptoGetBalance </TD><TD>Query</TD><TD>Response</TD>Retrieves the balance for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>getAccountInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the account information for an account by submitting the query.</P></TD> +<TD>getAccountInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the account information for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>getTransactionReceipts </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee.</P></TD> +<TD>getTransactionReceipts </TD><TD>Query</TD><TD>Response</TD>Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee.<TD><P></P></TD> </TR> <TR> -<TD>getFastTransactionRecord </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transaction record by TxID which last for 180sec only for no fee.</P></TD> +<TD>getFastTransactionRecord </TD><TD>Query</TD><TD>Response</TD>Retrieves the transaction record by TxID which last for 180sec only for no fee.<TD><P></P></TD> </TR> <TR> -<TD>getTxRecordByTxID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query.</P></TD> +<TD>getTxRecordByTxID </TD><TD>Query</TD><TD>Response</TD>Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query.<TD><P></P></TD> </TR> <TR> -<TD>getStakersByAccountID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the stakers for a node by account ID by submitting the query.</P></TD> +<TD>getStakersByAccountID </TD><TD>Query</TD><TD>Response</TD>Retrieves the stakers for a node by account ID by submitting the query.<TD><P></P></TD> </TR> <tbody> @@ -2935,8 +3212,9 @@ <H3 id="CryptoService"><span class="BigBadge">Service</span>CryptoService</H3> <H2 id="CryptoTransfer.proto">CryptoTransfer.proto</H2> <a href="#title">Top</a> </div> -<H3 id="AccountAmount"><span class="BigBadge">Message</span>AccountAmount</H3> <P> An account, and the amount that it sends or receives during a cryptocurrency transfer. </P> +<H3 id="AccountAmount"><span class="BigBadge">Message</span>AccountAmount</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3005,8 +3283,9 @@ <H3 id="TransferList"><span class="BigBadge">Message</span>TransferList</H3> <H2 id="CryptoUpdate.proto">CryptoUpdate.proto</H2> <a href="#title">Top</a> </div> -<H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>CryptoUpdateTransactionBody</H3> <P> Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. </P> +<H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>CryptoUpdateTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3155,8 +3434,9 @@ <H3 id="CryptoUpdateTransactionBody"><span class="BigBadge">Message</span>Crypto <H2 id="Duration.proto">Duration.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Duration"><span class="BigBadge">Message</span>Duration</H3> <P> The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) </P> +<H3 id="Duration"><span class="BigBadge">Message</span>Duration</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3179,8 +3459,9 @@ <H3 id="Duration"><span class="BigBadge">Message</span>Duration</H3> <H2 id="ExchangeRate.proto">ExchangeRate.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ExchangeRate"><span class="BigBadge">Message</span>ExchangeRate</H3> <P> Values from these proto denotes habr and cents(USD) conversion </P> +<H3 id="ExchangeRate"><span class="BigBadge">Message</span>ExchangeRate</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3241,8 +3522,9 @@ <H3 id="ExchangeRateSet"><span class="BigBadge">Message</span>ExchangeRateSet</H <H2 id="FileAppend.proto">FileAppend.proto</H2> <a href="#title">Top</a> </div> -<H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppendTransactionBody</H3> <P> Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. </P> +<H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppendTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3271,8 +3553,9 @@ <H3 id="FileAppendTransactionBody"><span class="BigBadge">Message</span>FileAppe <H2 id="FileCreate.proto">FileCreate.proto</H2> <a href="#title">Top</a> </div> +<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.<BR>The file contains the given contents (possibly empty). The file will automatically disappear at the fileExpirationTime, unless its expiration is extended by another transaction before that time. If the file is deleted, then its contents will become empty and it will be marked as deleted until it expires, and then it will cease to exist. See FileGetInfoQuery for more information about files.<BR>The keys field is a list of keys. All the keys on the list must sign to create or modify a file, but only one of them needs to sign in order to delete the file. Each of those "keys" may itself be threshold key containing other keys (including other threshold keys). In other words, the behavior is an AND for create/modify, OR for delete. This is useful for acting as a revocation server. If it is desired to have the behavior be AND for all 3 operations (or OR for all 3), then the list should have only a single Key, which is a threshold key, with N=1 for OR, N=M for AND.<BR>If a file is created without ANY keys in the keys field, the file is immutable ONLY the expirationTime of the file can be changed using FileUpdate API. The file contents or its keys cannot be changed.<BR>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.<BR>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.</P> <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCreateTransactionBody</H3> -<P> Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3325,8 +3608,9 @@ <H3 id="FileCreateTransactionBody"><span class="BigBadge">Message</span>FileCrea <H2 id="FileDelete.proto">FileDelete.proto</H2> <a href="#title">Top</a> </div> -<H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDeleteTransactionBody</H3> <P> Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). </P> +<H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3349,8 +3633,9 @@ <H3 id="FileDeleteTransactionBody"><span class="BigBadge">Message</span>FileDele <H2 id="FileGetContents.proto">FileGetContents.proto</H2> <a href="#title">Top</a> </div> -<H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetContentsQuery</H3> <P> Get the contents of a file. The content field is empty (no bytes) if the file is empty. </P> +<H3 id="FileGetContentsQuery"><span class="BigBadge">Message</span>FileGetContentsQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3402,7 +3687,7 @@ <H3 id="FileGetContentsResponse"><span class="BigBadge">Message</span>FileGetCon </TABLE> <H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</span>FileGetContentsResponse.FileContents</H3> -<P> Response when the client sends the node FileGetContentsQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3431,8 +3716,9 @@ <H3 id="FileGetContentsResponse.FileContents"><span class="BigBadge">Message</sp <H2 id="FileGetInfo.proto">FileGetInfo.proto</H2> <a href="#title">Top</a> </div> -<H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery</H3> <P> Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. </P> +<H3 id="FileGetInfoQuery"><span class="BigBadge">Message</span>FileGetInfoQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3484,7 +3770,7 @@ <H3 id="FileGetInfoResponse"><span class="BigBadge">Message</span>FileGetInfoRes </TABLE> <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileGetInfoResponse.FileInfo</H3> -<P> Response when the client sends the node FileGetInfoQuery </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3531,6 +3817,7 @@ <H3 id="FileGetInfoResponse.FileInfo"><span class="BigBadge">Message</span>FileG <H2 id="FileService.proto">FileService.proto</H2> <a href="#title">Top</a> </div> +<P> The request and responses for different file services. </P> <H3 id="FileService"><span class="BigBadge">Service</span>FileService</H3> <P></P> <table class="field-table"> @@ -3544,35 +3831,35 @@ <H3 id="FileService"><span class="BigBadge">Service</span>FileService</H3> </thead> <tbody> <TR> -<TD>createFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>createFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>updateFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates a file by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>updateFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates a file by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>deleteFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>deleteFile </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>appendContent </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>appendContent </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>getFileContent </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the file content by submitting the query. The grpc server returns the Response</P></TD> +<TD>getFileContent </TD><TD>Query</TD><TD>Response</TD>Retrieves the file content by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>getFileInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the file information by submitting the query. The grpc server returns the Response</P></TD> +<TD>getFileInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the file information by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <tbody> @@ -3582,8 +3869,9 @@ <H3 id="FileService"><span class="BigBadge">Service</span>FileService</H3> <H2 id="FileUpdate.proto">FileUpdate.proto</H2> <a href="#title">Top</a> </div> +<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.<BR>If a file was created without ANY keys in the keys field, ONLY the expirationTime of the file can be changed using this call. The file contents or its keys cannot be changed.</P> <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpdateTransactionBody</H3> -<P> Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3624,8 +3912,9 @@ <H3 id="FileUpdateTransactionBody"><span class="BigBadge">Message</span>FileUpda <H2 id="Freeze.proto">Freeze.proto</H2> <a href="#title">Top</a> </div> -<H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransactionBody</H3> <P> Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. </P> +<H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3666,6 +3955,7 @@ <H3 id="FreezeTransactionBody"><span class="BigBadge">Message</span>FreezeTransa <H2 id="FreezeService.proto">FreezeService.proto</H2> <a href="#title">Top</a> </div> +<P> The request and responses for freeze service. </P> <H3 id="FreezeService"><span class="BigBadge">Service</span>FreezeService</H3> <P></P> <table class="field-table"> @@ -3679,7 +3969,7 @@ <H3 id="FreezeService"><span class="BigBadge">Service</span>FreezeService</H3> </thead> <tbody> <TR> -<TD>freeze </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>freeze </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <tbody> @@ -3689,6 +3979,7 @@ <H3 id="FreezeService"><span class="BigBadge">Service</span>FreezeService</H3> <H2 id="GetByKey.proto">GetByKey.proto</H2> <a href="#title">Top</a> </div> +<P> Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. </P> <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> <P> the ID for a single entity (account, claim, file, or smart contract instance) </P> <table class="field-table"> @@ -3748,7 +4039,7 @@ <H3 id="EntityID"><span class="BigBadge">Message</span>EntityID</H3> </TABLE> <H3 id="GetByKeyQuery"><span class="BigBadge">Message</span>GetByKeyQuery</H3> -<P> Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. </P> +<P></P> <table class="field-table"> <thead> <TR> @@ -3803,8 +4094,9 @@ <H3 id="GetByKeyResponse"><span class="BigBadge">Message</span>GetByKeyResponse< <H2 id="GetBySolidityID.proto">GetBySolidityID.proto</H2> <a href="#title">Top</a> </div> -<H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidityIDQuery</H3> <P> Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. </P> +<H3 id="GetBySolidityIDQuery"><span class="BigBadge">Message</span>GetBySolidityIDQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -3871,8 +4163,9 @@ <H3 id="GetBySolidityIDResponse"><span class="BigBadge">Message</span>GetBySolid <H2 id="Query.proto">Query.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <P> A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. </P> +<H3 id="Query"><span class="BigBadge">Message</span>Query</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -4011,6 +4304,7 @@ <H3 id="Query"><span class="BigBadge">Message</span>Query</H3> <H2 id="QueryHeader.proto">QueryHeader.proto</H2> <a href="#title">Top</a> </div> +<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of GetInfo request. </P> <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> <P> Each query from the client to the node will contain the QueryHeader, which gives the requested response type, and includes a payment for the response. It will sometimes leave payment blank: it is blank for TransactionGetReceiptQuery. It can also be left blank when the responseType is costAnswer or costAnswerStateProof. But it needs to be filled in for all other cases. The idea is that an answer that is only a few bytes (or that was paid for earlier) can be given for free. But if the answer is something that requires many bytes or much computation (like a state proof), then it should be paid for. </P> <table class="field-table"> @@ -4038,7 +4332,7 @@ <H3 id="QueryHeader"><span class="BigBadge">Message</span>QueryHeader</H3> </TABLE> <H3 id="ResponseType"><span class="BigBadge">Enum</span>ResponseType</H3> -<P> The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. </P> +<P></P> <table class="enum-table"> <thead> <TR> @@ -4074,8 +4368,9 @@ <H3 id="ResponseType"><span class="BigBadge">Enum</span>ResponseType</H3> <H2 id="Response.proto">Response.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Response"><span class="BigBadge">Message</span>Response</H3> <P> A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. </P> +<H3 id="Response"><span class="BigBadge">Message</span>Response</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -4816,12 +5111,12 @@ <H3 id="ResponseCodeEnum"><span class="BigBadge">Enum</span>ResponseCodeEnum</H3 <TR> <TD>AUTORENEW_ACCOUNT_NOT_ALLOWED</TD> -<TD><P></P></TD> +<TD><P> An adminKey was not specified on the topic, so there must not be an autoRenewAccount.</P></TD> </TR> <TR> <TD>TOPIC_EXPIRED</TD> -<TD><P></P></TD> +<TD><P> The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI.</P></TD> </TR> <tbody> @@ -4831,8 +5126,9 @@ <H3 id="ResponseCodeEnum"><span class="BigBadge">Enum</span>ResponseCodeEnum</H3 <H2 id="ResponseHeader.proto">ResponseHeader.proto</H2> <a href="#title">Top</a> </div> -<H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> <P> Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. </P> +<H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -4873,6 +5169,7 @@ <H3 id="ResponseHeader"><span class="BigBadge">Message</span>ResponseHeader</H3> <H2 id="SmartContractService.proto">SmartContractService.proto</H2> <a href="#title">Top</a> </div> +<P> The request and responses for different smart contract services. </P> <H3 id="SmartContractService"><span class="BigBadge">Service</span>SmartContractService</H3> <P></P> <table class="field-table"> @@ -4886,47 +5183,47 @@ <H3 id="SmartContractService"><span class="BigBadge">Service</span>SmartContract </thead> <tbody> <TR> -<TD>createContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>createContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>updateContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>updateContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>contractCallMethod </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse</P></TD> +<TD>contractCallMethod </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>getContractInfo </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the contract information by submitting the query. The grpc server returns the Response</P></TD> +<TD>getContractInfo </TD><TD>Query</TD><TD>Response</TD>Retrieves the contract information by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>contractCallLocalMethod </TD><TD>Query</TD><TD>Response</TD><TD><P>Calls a smart contract by submitting the query. The grpc server returns the Response</P></TD> +<TD>contractCallLocalMethod </TD><TD>Query</TD><TD>Response</TD>Calls a smart contract by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>ContractGetBytecode </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response</P></TD> +<TD>ContractGetBytecode </TD><TD>Query</TD><TD>Response</TD>Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>getBySolidityID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response</P></TD> +<TD>getBySolidityID </TD><TD>Query</TD><TD>Response</TD>Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>getTxRecordByContractID </TD><TD>Query</TD><TD>Response</TD><TD><P>Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response</P></TD> +<TD>getTxRecordByContractID </TD><TD>Query</TD><TD>Response</TD>Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response<TD><P></P></TD> </TR> <TR> -<TD>deleteContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse</P></TD> +<TD>deleteContract </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>systemDelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <TR> -<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD><TD><P>UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse</P></TD> +<TD>systemUndelete </TD><TD>Transaction</TD><TD>TransactionResponse</TD>UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse<TD><P></P></TD> </TR> <tbody> @@ -4936,8 +5233,9 @@ <H3 id="SmartContractService"><span class="BigBadge">Service</span>SmartContract <H2 id="SystemDelete.proto">SystemDelete.proto</H2> <a href="#title">Top</a> </div> -<H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>SystemDeleteTransactionBody</H3> <P> Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>SystemDeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -4992,8 +5290,9 @@ <H3 id="SystemDeleteTransactionBody"><span class="BigBadge">Message</span>System <H2 id="SystemUndelete.proto">SystemUndelete.proto</H2> <a href="#title">Top</a> </div> -<H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>SystemUndeleteTransactionBody</H3> <P> Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. </P> +<H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>SystemUndeleteTransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5042,8 +5341,9 @@ <H3 id="SystemUndeleteTransactionBody"><span class="BigBadge">Message</span>Syst <H2 id="Timestamp.proto">Timestamp.proto</H2> <a href="#title">Top</a> </div> -<H3 id="Timestamp"><span class="BigBadge">Message</span>Timestamp</H3> <P> 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) </P> +<H3 id="Timestamp"><span class="BigBadge">Message</span>Timestamp</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5092,8 +5392,9 @@ <H3 id="TimestampSeconds"><span class="BigBadge">Message</span>TimestampSeconds< <H2 id="Transaction.proto">Transaction.proto</H2> <a href="#title">Top</a> </div> +<P> 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.<BR>The SignatureList field is deprecated and succeeded by SignatureMap.</P> <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> -<P> 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.</P> +<P></P> <table class="field-table"> <thead> <TR> @@ -5154,8 +5455,9 @@ <H3 id="Transaction"><span class="BigBadge">Message</span>Transaction</H3> <H2 id="TransactionBody.proto">TransactionBody.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H3> <P> A single transaction. All transaction types are possible here. </P> +<H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5354,8 +5656,9 @@ <H3 id="TransactionBody"><span class="BigBadge">Message</span>TransactionBody</H <H2 id="TransactionGetFastRecord.proto">TransactionGetFastRecord.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>TransactionGetFastRecordQuery</H3> <P> Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). </P> +<H3 id="TransactionGetFastRecordQuery"><span class="BigBadge">Message</span>TransactionGetFastRecordQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5410,8 +5713,9 @@ <H3 id="TransactionGetFastRecordResponse"><span class="BigBadge">Message</span>T <H2 id="TransactionGetReceipt.proto">TransactionGetReceipt.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>TransactionGetReceiptQuery</H3> <P> Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response</P> +<H3 id="TransactionGetReceiptQuery"><span class="BigBadge">Message</span>TransactionGetReceiptQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5466,8 +5770,9 @@ <H3 id="TransactionGetReceiptResponse"><span class="BigBadge">Message</span>Tran <H2 id="TransactionGetRecord.proto">TransactionGetRecord.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>TransactionGetRecordQuery</H3> <P> Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. </P> +<H3 id="TransactionGetRecordQuery"><span class="BigBadge">Message</span>TransactionGetRecordQuery</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5522,8 +5827,9 @@ <H3 id="TransactionGetRecordResponse"><span class="BigBadge">Message</span>Trans <H2 id="TransactionReceipt.proto">TransactionReceipt.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionReceipt</H3> <P> The consensus result for a transaction, which might not be currently known, or may succeed or fail. </P> +<H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionReceipt</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5572,13 +5878,13 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <TR> <TD>topicSequenceNumber</TD> <TD>uint64</TD> -<TD><P></P></TD> +<TD><P> Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <TR> <TD>topicRunningHash</TD> <TD>bytes</TD> -<TD><P></P></TD> +<TD><P> Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage.</P></TD> </TR> <tbody> @@ -5588,8 +5894,9 @@ <H3 id="TransactionReceipt"><span class="BigBadge">Message</span>TransactionRece <H2 id="TransactionRecord.proto">TransactionRecord.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecord</H3> <P> Response when the client sends the node TransactionGetRecordResponse </P> +<H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecord</H3> +<P></P> <table class="field-table"> <thead> <TR> @@ -5680,8 +5987,9 @@ <H3 id="TransactionRecord"><span class="BigBadge">Message</span>TransactionRecor <H2 id="TransactionResponse.proto">TransactionResponse.proto</H2> <a href="#title">Top</a> </div> -<H3 id="TransactionResponse"><span class="BigBadge">Message</span>TransactionResponse</H3> <P> When the client sends the node a transaction of any kind, the node replies with this, which simply says that the transaction passed the precheck (so the node will submit it to the network) or it failed (so it won't). If the fee offered was insufficient, this will also contain the amount of the required fee. To learn the consensus result, the client should later obtain a receipt (free), or can buy a more detailed record (not free). </P> +<H3 id="TransactionResponse"><span class="BigBadge">Message</span>TransactionResponse</H3> +<P></P> <table class="field-table"> <thead> <TR> diff --git a/docs/NotNestedDoc.md b/docs/NotNestedDoc.md index 7a430f7b..f9751faf 100644 --- a/docs/NotNestedDoc.md +++ b/docs/NotNestedDoc.md @@ -18,7 +18,7 @@ - [NodeAddress](#NodeAddress) - [NodeAddressBook](#NodeAddressBook) - [RealmID](#RealmID) - - [ServicesConfigurationLis](#ServicesConfigurationLis) + - [ServicesConfigurationList](#ServicesConfigurationList) - [Setting](#Setting) - [ShardID](#ShardID) - [Signature](#Signature) @@ -32,10 +32,14 @@ - [TransactionID](#TransactionID) - [ConsensusCreateTopic.proto](#ConsensusCreateTopic.proto) + - [ConsensusCreateTopicTransactionBody](#ConsensusCreateTopicTransactionBody) - [ConsensusDeleteTopic.proto](#ConsensusDeleteTopic.proto) + - [ConsensusDeleteTopicTransactionBody](#ConsensusDeleteTopicTransactionBody) - [ConsensusGetTopicInfo.proto](#ConsensusGetTopicInfo.proto) + - [ConsensusGetTopicInfoQuery](#ConsensusGetTopicInfoQuery) + - [ConsensusGetTopicInfoResponse](#ConsensusGetTopicInfoResponse) - [ConsensusService.proto](#ConsensusService.proto) - [ConsensusService](#ConsensusService) (Service) @@ -44,8 +48,10 @@ - [ConsensusSubmitMessageTransactionBody](#ConsensusSubmitMessageTransactionBody) - [ConsensusTopicInfo.proto](#ConsensusTopicInfo.proto) + - [ConsensusTopicInfo](#ConsensusTopicInfo) - [ConsensusUpdateTopic.proto](#ConsensusUpdateTopic.proto) + - [ConsensusUpdateTopicTransactionBody](#ConsensusUpdateTopicTransactionBody) - [ContractCall.proto](#ContractCall.proto) - [ContractCallTransactionBody](#ContractCallTransactionBody) @@ -233,6 +239,8 @@ ## BasicTypes.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. + <a name="AccountID"></a> ### AccountID @@ -377,7 +385,7 @@ <a name="Key"></a> ### Key - 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 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.<BR>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.<BR>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.<BR>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.<BR>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.<BR>Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -434,9 +442,9 @@ | realmNum | | The realm number (nonnegative) | | -<a name="ServicesConfigurationLis"></a> +<a name="ServicesConfigurationList"></a> -### ServicesConfigurationLis +### ServicesConfigurationList | Field | Type | Description | | @@ -459,7 +467,7 @@ <a name="ShardID"></a> ### ShardID - 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. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -469,7 +477,7 @@ <a name="Signature"></a> ### Signature - 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. + 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.<BR>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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -486,7 +494,7 @@ <a name="SignatureList"></a> ### SignatureList - The signatures corresponding to a KeyList of the same length. + The signatures corresponding to a KeyList of the same length.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -497,7 +505,7 @@ <a name="SignatureMap"></a> ### SignatureMap - A set of signatures corresponding to every unique public key used to sign a given transaction. + A set of signatures corresponding to every unique public key used to sign a given transaction.<BR>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. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -507,7 +515,7 @@ <a name="SignaturePair"></a> ### SignaturePair - The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix. + The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.<BR>If 0 bytes is used, then it is assumed that only one public key is used to sign. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -533,7 +541,7 @@ <a name="ThresholdSignature"></a> ### ThresholdSignature - 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. + 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.<BR>This message is deprecated and succeeded by SignaturePair and SignatureMap messages. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -580,21 +588,76 @@ ## ConsensusCreateTopic.proto + See [ConsensusService.createTopic()](#proto.ConsensusService) + +<a name="ConsensusCreateTopicTransactionBody"></a> + +### ConsensusCreateTopicTransactionBody + + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| memo | | Short publicly visible memo about the topic. No guarantee of uniqueness. | | +| adminKey | [Key](#Key) | Access control for updateTopic/deleteTopic.<BR>Anyone can increase the topic's expirationTime via ConsensusService.updateTopic(), regardless of the adminKey.<BR>If no adminKey is specified, updateTopic may only be used to extend the topic's expirationTime, and deleteTopic<BR>is disallowed. | | +| submitKey | [Key](#Key) | Access control for submitMessage.<BR>If unspecified, no access control is performed on ConsensusService.submitMessage (all submissions are allowed). | | +| autoRenewPeriod | [Duration](#Duration) | The initial lifetime of the topic and the amount of time to attempt to extend the topic's lifetime by<BR>automatically at the topic's expirationTime, if the autoRenewAccount is configured (once autoRenew functionality<BR>is supported by HAPI).<BR>Limited to MIN_AUTORENEW_PERIOD and MAX_AUTORENEW_PERIOD value by server-side configuration.<BR>Required. | | +| autoRenewAccount | [AccountID](#AccountID) | Optional account to be used at the topic's expirationTime to extend the life of the topic (once autoRenew<BR>functionality is supported by HAPI).<BR>The topic lifetime will be extended up to a maximum of the autoRenewPeriod or however long the topic<BR>can be extended using all funds on the account (whichever is the smaller duration/amount and if any extension<BR>is possible with the account's funds).<BR>If specified, there must be an adminKey and the autoRenewAccount must sign this transaction. | | + + <a name="ConsensusDeleteTopic.proto"></a> <p align="right"><a href="#top">Top</a></p> ## ConsensusDeleteTopic.proto + See [ConsensusService.deleteTopic()](#proto.ConsensusService) + +<a name="ConsensusDeleteTopicTransactionBody"></a> + +### ConsensusDeleteTopicTransactionBody + + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| topicID | [TopicID](#TopicID) | Topic identifier. | | + + <a name="ConsensusGetTopicInfo.proto"></a> <p align="right"><a href="#top">Top</a></p> ## ConsensusGetTopicInfo.proto + See [ConsensusService.getTopicInfo()](#proto.ConsensusService) + +<a name="ConsensusGetTopicInfoQuery"></a> + +### ConsensusGetTopicInfoQuery + + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| header | [QueryHeader](#QueryHeader) | Standard info sent from client to node, including the signed payment, and what kind of response is requested<BR>(cost, state proof, both, or neither). | | +| topicID | [TopicID](#TopicID) | Topic to retrieve info about (the parameters and running state of). | | + + +<a name="ConsensusGetTopicInfoResponse"></a> + +### ConsensusGetTopicInfoResponse + Retrieve the parameters of and state of a consensus topic. + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| header | [ResponseHeader](#ResponseHeader) | Standard response from node to client, including the requested fields: cost, or state proof, or both, or neither. | | +| topicID | [TopicID](#TopicID) | Topic identifier. | | +| topicInfo | [ConsensusTopicInfo](#ConsensusTopicInfo) | Current state of the topic | | + + <a name="ConsensusService.proto"></a> <p align="right"><a href="#top">Top</a></p> ## ConsensusService.proto + The Consensus Service provides the ability for Hedera Hashgraph to provide aBFT consensus as to the order and<BR>validity of messages submitted to a topic, as well as a consensus timestamp for those messages.<BR>Automatic renewal can be configured via an autoRenewAccount.<BR>Any time an autoRenewAccount is added to a topic, that createTopic/updateTopic transaction must be signed by<BR>the autoRenewAccount.<BR>The autoRenewPeriod on an account must currently be set a value in createTopic between MIN_AUTORENEW_PERIOD (6999999<BR>seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds). During creation this sets the initial expirationTime of the<BR>topic (see more below).<BR>If no adminKey is on a topic, there may not be an autoRenewAccount on the topic, deleteTopic is not allowed,<BR>and the only change allowed via an updateTopic is to extend the expirationTime.<BR>If an adminKey is on a topic, every updateTopic and deleteTopic transaction must be signed by the adminKey, except<BR>for updateTopics which only extend the topic's expirationTime (no adminKey authorization required).<BR>If an updateTopic modifies the adminKey of a topic, the transaction signatures on the updateTopic must fulfill both<BR>the pre-update and post-update adminKey signature requirements.<BR>Mirrornet ConsensusService may be used to subscribe to changes on the topic, including changes to the topic<BR>definition and the consensus ordering and timestamp of submitted messages.<BR>Until autoRenew functionality is supported by HAPI, the topic will not expire, the autoRenewAccount will not be<BR>charged, and the topic will not automatically be deleted.<BR>Once autoRenew functionality is supported by HAPI:<BR>1. Once the expirationTime is encountered, if an autoRenewAccount is configured on the topic, the account will be<BR>charged automatically at the expirationTime, to extend the expirationTime of the topic up to the topic's<BR>autoRenewPeriod (or as much extension as the account's balance will supply).<BR>2. If the topic expires and is not automatically renewed, the topic will enter the EXPIRED state. All transactions<BR>on the topic will fail with TOPIC_EXPIRED, except an updateTopic() call that modifies only the expirationTime.<BR>getTopicInfo() will succeed. This state will be available for a AUTORENEW_GRACE_PERIOD grace period (7 days).<BR>3. After the grace period, if the topic's expirationTime is not extended, the topic will be automatically<BR>deleted and no transactions or queries on the topic will succeed after that point. + <a name="ConsensusService"></a> ### ConsensusService @@ -602,11 +665,11 @@ | RPC | Request | Response | Comments | | --- | ------- | -------- | -------- | -| createTopic | Transaction | TransactionResponse); | -| updateTopic | Transaction | TransactionResponse); | -| deleteTopic | Transaction | TransactionResponse); | -| getTopicInfo | Query | Response); | -| submitMessage | Transaction | TransactionResponse); | +| createTopic | Transaction | TransactionResponse | Create a topic to be used for consensus.<BR>If an autoRenewAccount is specified, that account must also sign this transaction.<BR>If an adminKey is specified, the adminKey must sign the transaction.<BR>On success, the resulting TransactionReceipt contains the newly created TopicId.<BR>Request is [ConsensusCreateTopicTransactionBody](#proto.ConsensusCreateTopicTransactionBody) | +| updateTopic | Transaction | TransactionResponse | Update a topic.<BR>If there is no adminKey, the only authorized update (available to anyone) is to extend the expirationTime.<BR>Otherwise transaction must be signed by the adminKey.<BR>If an adminKey is updated, the transaction must be signed by the pre-update adminKey and post-update adminKey.<BR>If a new autoRenewAccount is specified (not just being removed), that account must also sign the transaction.<BR>Request is [ConsensusUpdateTopicTransactionBody](#proto.ConsensusUpdateTopicTransactionBody) | +| deleteTopic | Transaction | TransactionResponse | Delete a topic. No more transactions or queries on the topic (via HAPI) will succeed.<BR>If an adminKey is set, this transaction must be signed by that key.<BR>If there is no adminKey, this transaction will fail UNAUTHORIZED.<BR>Request is [ConsensusDeleteTopicTransactionBody](#proto.ConsensusDeleteTopicTransactionBody) | +| getTopicInfo | Query | Response | Retrieve the latest state of a topic. This method is unrestricted and allowed on any topic by any payer account.<BR>Deleted accounts will not be returned.<BR>Request is [ConsensusGetTopicInfoQuery](#proto.ConsensusGetTopicInfoQuery)<BR>Response is [ConsensusGetTopicInfoResponse](#proto.ConsensusGetTopicInfoResponse) | +| submitMessage | Transaction | TransactionResponse | Submit a message for consensus.<BR>Valid and authorized messages on valid topics will be ordered by the consensus service, gossipped to the<BR>mirror net, and published (in order) to all subscribers (from the mirror net) on this topic.<BR>The submitKey (if any) must sign this transaction.<BR>On success, the resulting TransactionReceipt contains the topic's updated topicSequenceNumber and<BR>topicRunningHash.<BR>Request is [ConsensusSubmitMessageTransactionBody](#proto.ConsensusSubmitMessageTransactionBody) | <a name="ConsensusSubmitMessage.proto"></a> @@ -630,20 +693,59 @@ ## ConsensusTopicInfo.proto + Current state of a topic. + +<a name="ConsensusTopicInfo"></a> + +### ConsensusTopicInfo + + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| memo | | Short publicly visible memo about the topic. No guarantee of uniqueness. | | +| runningHash | | SHA-384 running hash <previousRunningHash, topicId, consensusTimestamp, sequenceNumber, message> | | +| sequenceNumber | | Sequence number (starting at 1 for the first submitMessage) of messages on the topic. | | +| expirationTime | [Timestamp](#Timestamp) | Effective consensus timestamp at (and after) which submitMessage calls will no longer succeed on the topic<BR>and the topic will expire and after AUTORENEW_GRACE_PERIOD be automatically deleted. | | +| adminKey | [Key](#Key) | Access control for update/delete of the topic. Null if there is no key. | | +| submitKey | [Key](#Key) | Access control for ConsensusService.submitMessage. Null if there is no key. | | +| autoRenewPeriod | [Duration](#Duration) | | | +| autoRenewAccount | [AccountID](#AccountID) | Null if there is no autoRenewAccount. | | + + <a name="ConsensusUpdateTopic.proto"></a> <p align="right"><a href="#top">Top</a></p> ## ConsensusUpdateTopic.proto + All fields left null will not be updated.<BR>See [ConsensusService.updateTopic()](#proto.ConsensusService) + +<a name="ConsensusUpdateTopicTransactionBody"></a> + +### ConsensusUpdateTopicTransactionBody + + +| Field | Type | Description | | +| ----- | ---- | ----------- | - | +| topicID | [TopicID](#TopicID) | | | +| memo | [google.protobuf.StringValue](#google.protobuf.StringValue) | Short publicly visible memo about the topic. No guarantee of uniqueness. Null for "do not update". | | +| expirationTime | [Timestamp](#Timestamp) | Effective consensus timestamp at (and after) which all consensus transactions and queries will fail.<BR>The expirationTime may be no longer than MAX_AUTORENEW_PERIOD (8000001 seconds) from the consensus timestamp of<BR>this transaction.<BR>On topics with no adminKey, extending the expirationTime is the only updateTopic option allowed on the topic.<BR>If unspecified, no change. | | +| adminKey | [Key](#Key) | Access control for update/delete of the topic.<BR>If unspecified, no change.<BR>If empty keyList - the adminKey is cleared. | | +| submitKey | [Key](#Key) | Access control for ConsensusService.submitMessage.<BR>If unspecified, no change.<BR>If empty keyList - the submitKey is cleared. | | +| autoRenewPeriod | [Duration](#Duration) | The amount of time to extend the topic's lifetime automatically at expirationTime if the autoRenewAccount is<BR>configured and has funds (once autoRenew functionality is supported by HAPI).<BR>Limited to between MIN_AUTORENEW_PERIOD (6999999 seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds) by<BR>servers-side configuration (which may change).<BR>If unspecified, no change. | | +| autoRenewAccount | [AccountID](#AccountID) | Optional account to be used at the topic's expirationTime to extend the life of the topic.<BR>Once autoRenew functionality is supported by HAPI, the topic lifetime will be extended up to a maximum of the<BR>autoRenewPeriod or however long the topic can be extended using all funds on the account (whichever is the<BR>smaller duration/amount).<BR>If specified as the default value (0.0.0), the autoRenewAccount will be removed.<BR>If unspecified, no change. | | + + <a name="ContractCall.proto"></a> <p align="right"><a href="#top">Top</a></p> ## ContractCall.proto + Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account.<BR>If this function stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee. + <a name="ContractCallTransactionBody"></a> ### ContractCallTransactionBody - Call a function of the given smart contract instance, giving it functionParameters as its inputs. it can use the given amount of gas, and any unspent gas will be refunded to the paying account. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -658,10 +760,12 @@ ## ContractCallLocal.proto + The log information for an event returned by a smart contract function call. One function call may return several such events. + <a name="ContractCallLocalQuery"></a> ### ContractCallLocalQuery - Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas. + Call a function of the given smart contract instance, giving it functionParameters as its inputs. It will consume the entire given amount of gas.<BR>This is performed locally on the particular node that the client is communicating with. It cannot change the state of the contract instance (and so, cannot spend anything from the instance's cryptocurrency account). It will not have a consensus timestamp. It cannot generate a record or a receipt. The response will contain the output returned by the function call. This is useful for calling getter functions, which purely read the state and don't change it. It is faster and cheaper than a normal call, because it is purely local to a single node. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -701,7 +805,7 @@ <a name="ContractLoginfo"></a> ### ContractLoginfo - The log information for an event returned by a smart contract function call. One function call may return several such events. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -716,10 +820,12 @@ ## ContractCreate.proto + Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters.<BR>The instance will exist for autoRenewPeriod seconds. When that is reached, it will renew itself for another autoRenewPeriod seconds by charging its associated cryptocurrency account (which it creates here). If it has insufficient cryptocurrency to extend that long, it will extend as long as it can. If its balance is zero, the instance will be deleted.<BR>A smart contract instance normally enforces rules, so "the code is law". For example, an ERC-20 contract prevents a transfer from being undone without a signature by the recipient of the transfer. This is always enforced if the contract instance was created with the adminKeys being null. But for some uses, it might be desirable to create something like an ERC-20 contract that has a specific group of trusted individuals who can act as a "supreme court" with the ability to override the normal operation, when a sufficient number of them agree to do so. If adminKeys is not null, then they can sign a transaction that can change the state of the smart contract in arbitrary ways, such as to reverse a transaction that violates some standard of behavior that is not covered by the code itself. The admin keys can also be used to change the autoRenewPeriod, and change the adminKeys field itself. The API currently does not implement this ability. But it does allow the adminKeys field to be set and queried, and will in the future implement such admin abilities for any instance that has a non-null adminKeys.<BR>If this constructor stores information, it is charged gas to store it. There is a fee in hbars to maintain that storage until the expiration time, and that fee is added as part of the transaction fee.<BR>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.<BR>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.<BR>The optional memo field can contain a string whose length is up to 100 bytes. That is the size after Unicode NFD then UTF-8 conversion. This field can be used to describe the smart contract. It could also be used for other purposes. One recommended purpose is to hold a hexadecimal string that is the SHA-384 hash of a PDF file containing a human-readable legal contract. Then, if the admin keys are the public keys of human arbitrators, they can use that legal document to guide their decisions during a binding arbitration tribunal, convened to consider any changes to the smart contract in the future. The memo field can only be changed using the admin keys. If there are no admin keys, then it cannot be changed after the smart contract is created. + <a name="ContractCreateTransactionBody"></a> ### ContractCreateTransactionBody - Start a new smart contract instance. After the instance is created, the ContractID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The instance will run the bytecode stored in the given file, referenced either by FileID or by the transaction ID of the transaction that created the file. The constructor will be executed using the given amount of gas, and any unspent gas will be refunded to the paying account. Constructor inputs come from the given constructorParameters. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -741,10 +847,12 @@ ## ContractDelete.proto + Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. + <a name="ContractDeleteTransactionBody"></a> ### ContractDeleteTransactionBody - Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the mangement of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -759,10 +867,12 @@ ## ContractGetBytecode.proto + Get the bytecode for a smart contract instance + <a name="ContractGetBytecodeQuery"></a> ### ContractGetBytecodeQuery - Get the bytecode for a smart contract instance + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -786,10 +896,12 @@ ## ContractGetInfo.proto + Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. + <a name="ContractGetInfoQuery"></a> ### ContractGetInfoQuery - Get information about a smart contract instance. This includes the account that it uses, the file containing its bytecode, and the time when it will expire. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -811,7 +923,7 @@ <a name="ContractGetInfoResponse.ContractInfo"></a> ### ContractGetInfoResponse.ContractInfo - Response when the client sends the node ContractGetInfoQuery + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -831,10 +943,12 @@ ## ContractGetRecords.proto + Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. + <a name="ContractGetRecordsQuery"></a> ### ContractGetRecordsQuery - Get all the records for a smart contract instance, for any function call (or the constructor call) during the last 25 hours, for which a Record was requested. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -859,10 +973,12 @@ ## ContractUpdate.proto + Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. + <a name="ContractUpdateTransactionBody"></a> ### ContractUpdateTransactionBody - Modify a smart contract instance to have the given parameter values. Any null field is ignored (left unchanged). If only the contractInstanceExpirationTime is being modified, then no signature is needed on this transaction other than for the account paying for the transaction itself. But if any of the other fields are being modified, then it must be signed by the adminKey. The use of adminKey is not currently supported in this API, but in the future will be implemented to allow these fields to be modified, and also to make modifications to the state of the instance. If the contract is created with no admin key, then none of the fields can be changed that need an admin signature, and therefore no admin key can ever be added. So if there is no admin key, then things like the bytecode are immutable. But if there is an admin key, then they can be changed. For example, the admin key might be a threshold key, which requires 3 of 5 binding arbitration judges to agree before the bytecode can be changed. This can be used to add flexibility to the management of smart contract behavior. But this is optional. If the smart contract is created without an admin key, then such a key can never be added, and its bytecode will be immutable. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -880,10 +996,12 @@ ## CryptoAddClaim.proto + A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. + <a name="Claim"></a> ### Claim - A hash (presumably of some kind of credential or certificate), along with a list of keys (each of which is either a primitive or a threshold key). Each of them must reach its threshold when signing the transaction, to attach this claim to this account. At least one of them must reach its threshold to delete this Claim from this account. This is intended to provide a revocation service: all the authorities agree to attach the hash, to attest to the fact that the credential or certificate is valid. Any one of the authorities can later delete the hash, to indicate that the credential has been revoked. In this way, any client can prove to a third party that any particular account has certain credentials, or to identity facts proved about it, and that none of them have been revoked yet. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -896,7 +1014,7 @@ <a name="CryptoAddClaimTransactionBody"></a> ### CryptoAddClaimTransactionBody - Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time. + Attach the given hash to the given account. The hash can be deleted by the keys used to transfer money from the account. The hash can also be deleted by any one of the deleteKeys (where that one may itself be a threshold key made up of multiple keys). Therefore, this acts as a revocation service for claims about the account. External authorities may issue certificates or credentials of some kind that make a claim about this account. The account owner can then attach a hash of that claim to the account. The transaction that adds the claim will be signed by the owner of the account, and also by all the authorities that are attesting to the truth of that claim. If the claim ever ceases to be true, such as when a certificate is revoked, then any one of the listed authorities has the ability to delete it. The account owner also has the ability to delete it at any time.<BR>In this way, it acts as a revocation server, and the account owner can prove to any third party that the claim is still true for this account, by sending the third party the signed credential, and then having the third party query to discover whether the hash of that credential is still attached to the account.<BR>For a given account, each Claim must contain a different hash. To modify the list of keys in a Claim, the existing Claim should first be deleted, then the Claim with the new list of keys can be added. | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -908,10 +1026,12 @@ ## CryptoCreate.proto + Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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.<BR>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.<BR>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. + <a name="CryptoCreateTransactionBody"></a> ### CryptoCreateTransactionBody - Create a new account. After the account is created, the AccountID for it is in the receipt, or can be retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. The account can then automatically generate records for large transfers into it or out of it, which each last for 25 hours. Records are generated for any transfer that exceeds the thresholds given here. This account is charged cryptocurrency 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. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -932,10 +1052,12 @@ ## CryptoDelete.proto + Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. + <a name="CryptoDeleteTransactionBody"></a> ### CryptoDeleteTransactionBody - Mark an account as deleted, moving all its current hbars to another account. It will remain in the ledger, marked as deleted, until it expires. Transfers into it a deleted account fail. But a deleted account can still have its expiration extended in the normal way. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -948,10 +1070,12 @@ ## CryptoDeleteClaim.proto + Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. + <a name="CryptoDeleteClaimTransactionBody"></a> ### CryptoDeleteClaimTransactionBody - Delete a claim hash that was attached to the given account. This transaction is valid if signed by all the keys used for transfers out of the account. It is also valid if signed by any single ThresholdKeys in the deleteKeys list for this hash. See CryptoAddClaimTransaction for more information about claim hashes. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -964,10 +1088,12 @@ ## CryptoGetAccountBalance.proto + Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. + <a name="CryptoGetAccountBalanceQuery"></a> ### CryptoGetAccountBalanceQuery - Get the balance of a cryptocurrency account. This returns only the balance, so it is a smaller and faster reply than CryptoGetInfo, which returns the balance plus additional information. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -994,10 +1120,12 @@ ## CryptoGetAccountRecords.proto + Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. + <a name="CryptoGetAccountRecordsQuery"></a> ### CryptoGetAccountRecordsQuery - Get all the records for an account for any transfers into it and out of it, that were above the threshold, during the last 25 hours. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1022,10 +1150,12 @@ ## CryptoGetClaim.proto + Get a single claim attached to an account, or return null if it does not exist. + <a name="CryptoGetClaimQuery"></a> ### CryptoGetClaimQuery - Get a single claim attached to an account, or return null if it does not exist. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1050,10 +1180,12 @@ ## CryptoGetInfo.proto + Get all the information about an account, including the balance. This does not get the list of account records. + <a name="CryptoGetInfoQuery"></a> ### CryptoGetInfoQuery - Get all the information about an account, including the balance. This does not get the list of account records. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1075,7 +1207,7 @@ <a name="CryptoGetInfoResponse.AccountInfo"></a> ### CryptoGetInfoResponse.AccountInfo - Response when the client sends the node CryptoGetInfoQuery + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1099,6 +1231,8 @@ ## CryptoGetStakers.proto + Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. + <a name="AllProxyStakers"></a> ### AllProxyStakers @@ -1113,7 +1247,7 @@ <a name="CryptoGetStakersQuery"></a> ### CryptoGetStakersQuery - Get all the accounts that are proxy staking to this account. For each of them, give the amount currently staked. This is not yet implemented, but will be in a future version of the API. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1148,6 +1282,8 @@ ## CryptoService.proto + The request and responses for different crypto services. + <a name="CryptoService"></a> ### CryptoService @@ -1155,20 +1291,20 @@ | RPC | Request | Response | Comments | | --- | ------- | -------- | -------- | -| createAccount | Transaction | TransactionResponse | Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse | -| updateAccount | Transaction | TransactionResponse | Updates an account by submitting the transaction. The grpc server returns the TransactionResponse | -| cryptoTransfer | Transaction | TransactionResponse | Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse | -| cryptoDelete | Transaction | TransactionResponse | Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse | -| addClaim | Transaction | TransactionResponse | Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse | -| deleteClaim | Transaction | TransactionResponse | Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse | -| getClaim | Query | Response | Retrieves the claim for an account by submitting the query. | -| getAccountRecords | Query | Response | Retrieves the record(fetch by AccountID ID) for an account by submitting the query. | -| cryptoGetBalance | Query | Response | Retrieves the balance for an account by submitting the query. | -| getAccountInfo | Query | Response | Retrieves the account information for an account by submitting the query. | -| getTransactionReceipts | Query | Response | Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee. | -| getFastTransactionRecord | Query | Response | Retrieves the transaction record by TxID which last for 180sec only for no fee. | -| getTxRecordByTxID | Query | Response | Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query. | -| getStakersByAccountID | Query | Response | Retrieves the stakers for a node by account ID by submitting the query. | +| createAccount | Transaction | TransactionResponse | Creates a new account by submitting the transaction. The grpc server returns the TransactionResponse | +| updateAccount | Transaction | TransactionResponse | Updates an account by submitting the transaction. The grpc server returns the TransactionResponse | +| cryptoTransfer | Transaction | TransactionResponse | Initiates a transfer by submitting the transaction. The grpc server returns the TransactionResponse | +| cryptoDelete | Transaction | TransactionResponse | Deletes and account by submitting the transaction. The grpc server returns the TransactionResponse | +| addClaim | Transaction | TransactionResponse | Adds a claim by submitting the transaction. The grpc server returns the TransactionResponse | +| deleteClaim | Transaction | TransactionResponse | Deletes a claim by submitting the transaction. The grpc server returns the TransactionResponse | +| getClaim | Query | Response | Retrieves the claim for an account by submitting the query. | +| getAccountRecords | Query | Response | Retrieves the record(fetch by AccountID ID) for an account by submitting the query. | +| cryptoGetBalance | Query | Response | Retrieves the balance for an account by submitting the query. | +| getAccountInfo | Query | Response | Retrieves the account information for an account by submitting the query. | +| getTransactionReceipts | Query | Response | Retrieves the transaction receipts for an account by TxId which last for 180sec only for no fee. | +| getFastTransactionRecord | Query | Response | Retrieves the transaction record by TxID which last for 180sec only for no fee. | +| getTxRecordByTxID | Query | Response | Retrieves the transactions record(fetch by Transaction ID) for an account by submitting the query. | +| getStakersByAccountID | Query | Response | Retrieves the stakers for a node by account ID by submitting the query. | <a name="CryptoTransfer.proto"></a> @@ -1176,10 +1312,12 @@ ## CryptoTransfer.proto + An account, and the amount that it sends or receives during a cryptocurrency transfer. + <a name="AccountAmount"></a> ### AccountAmount - An account, and the amount that it sends or receives during a cryptocurrency transfer. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1212,10 +1350,12 @@ ## CryptoUpdate.proto + Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. + <a name="CryptoUpdateTransactionBody"></a> ### CryptoUpdateTransactionBody - Change properties for the given account. Any null field is ignored (left unchanged). This transaction must be signed by the existing key for this account. If the transaction is changing the key field, then the transaction must be signed by both the old key (from before the change) and the new key. The old key must sign for security. The new key must sign as a safeguard to avoid accidentally changing to an invalid key, and then having no way to recover. When extending the expiration date, the cost is affected by the size of the list of attached claims, and of the keys associated with the claims and the account. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1241,10 +1381,12 @@ ## Duration.proto + The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) + <a name="Duration"></a> ### Duration - The length of a period of time. This is an identical data structure to the protobuf Duration.proto (see the comments in https:github.com/google/protobuf/blob/master/src/google/protobuf/duration.proto) + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1256,10 +1398,12 @@ ## ExchangeRate.proto + Values from these proto denotes habr and cents(USD) conversion + <a name="ExchangeRate"></a> ### ExchangeRate - Values from these proto denotes habr and cents(USD) conversion + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1284,10 +1428,12 @@ ## FileAppend.proto + Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. + <a name="FileAppendTransactionBody"></a> ### FileAppendTransactionBody - Append the given contents to the end of the file. If a file is too big to create with a single FileCreateTransaction, then it can be created with the first part of its contents, and then appended multiple times to create the entire file. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1300,10 +1446,12 @@ ## FileCreate.proto + Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that.<BR>The file contains the given contents (possibly empty). The file will automatically disappear at the fileExpirationTime, unless its expiration is extended by another transaction before that time. If the file is deleted, then its contents will become empty and it will be marked as deleted until it expires, and then it will cease to exist. See FileGetInfoQuery for more information about files.<BR>The keys field is a list of keys. All the keys on the list must sign to create or modify a file, but only one of them needs to sign in order to delete the file. Each of those "keys" may itself be threshold key containing other keys (including other threshold keys). In other words, the behavior is an AND for create/modify, OR for delete. This is useful for acting as a revocation server. If it is desired to have the behavior be AND for all 3 operations (or OR for all 3), then the list should have only a single Key, which is a threshold key, with N=1 for OR, N=M for AND.<BR>If a file is created without ANY keys in the keys field, the file is immutable ONLY the expirationTime of the file can be changed using FileUpdate API. The file contents or its keys cannot be changed.<BR>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.<BR>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. + <a name="FileCreateTransactionBody"></a> ### FileCreateTransactionBody - Create a new file, containing the given contents. It is referenced by its FileID, and does not have a filename, so it is important to get the FileID. After the file is created, the FileID for it can be found in the receipt, or retrieved with a GetByKey query, or by asking for a Record of the transaction to be created, and retrieving that. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1320,10 +1468,12 @@ ## FileDelete.proto + Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). + <a name="FileDeleteTransactionBody"></a> ### FileDeleteTransactionBody - Delete the given file. After deletion, it will be marked as deleted and will have no contents. But information about it will continue to exist until it expires. A list of keys was given when the file was created. All the keys on that list must sign transactions to create or modify the file, but any single one of them can be used to delete the file. Each "key" on that list may itself be a threshold key containing other keys (including other threshold keys). + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1335,10 +1485,12 @@ ## FileGetContents.proto + Get the contents of a file. The content field is empty (no bytes) if the file is empty. + <a name="FileGetContentsQuery"></a> ### FileGetContentsQuery - Get the contents of a file. The content field is empty (no bytes) if the file is empty. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1360,7 +1512,7 @@ <a name="FileGetContentsResponse.FileContents"></a> ### FileGetContentsResponse.FileContents - Response when the client sends the node FileGetContentsQuery + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1373,10 +1525,12 @@ ## FileGetInfo.proto + Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. + <a name="FileGetInfoQuery"></a> ### FileGetInfoQuery - Get all of the information about a file, except for its contents. When a file expires, it no longer exists, and there will be no info about it, and the fileInfo field will be blank. If a transaction or smart contract deletes the file, but it has not yet expired, then the fileInfo field will be non-empty, the deleted field will be true, its size will be 0, and its contents will be empty. Note that each file has a FileID, but does not have a filename. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1398,7 +1552,7 @@ <a name="FileGetInfoResponse.FileInfo"></a> ### FileGetInfoResponse.FileInfo - Response when the client sends the node FileGetInfoQuery + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1414,6 +1568,8 @@ ## FileService.proto + The request and responses for different file services. + <a name="FileService"></a> ### FileService @@ -1421,14 +1577,14 @@ | RPC | Request | Response | Comments | | --- | ------- | -------- | -------- | -| createFile | Transaction | TransactionResponse | Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse | -| updateFile | Transaction | TransactionResponse | Updates a file by submitting the transaction. The grpc server returns the TransactionResponse | -| deleteFile | Transaction | TransactionResponse | Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse | -| appendContent | Transaction | TransactionResponse | Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse | -| getFileContent | Query | Response | Retrieves the file content by submitting the query. The grpc server returns the Response | -| getFileInfo | Query | Response | Retrieves the file information by submitting the query. The grpc server returns the Response | -| systemDelete | Transaction | TransactionResponse | Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | -| systemUndelete | Transaction | TransactionResponse | UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | +| createFile | Transaction | TransactionResponse | Creates a file with the content by submitting the transaction. The grpc server returns the TransactionResponse | +| updateFile | Transaction | TransactionResponse | Updates a file by submitting the transaction. The grpc server returns the TransactionResponse | +| deleteFile | Transaction | TransactionResponse | Deletes a file by submitting the transaction. The grpc server returns the TransactionResponse | +| appendContent | Transaction | TransactionResponse | Appends the file contents(for a given FileID) by submitting the transaction. The grpc server returns the TransactionResponse | +| getFileContent | Query | Response | Retrieves the file content by submitting the query. The grpc server returns the Response | +| getFileInfo | Query | Response | Retrieves the file information by submitting the query. The grpc server returns the Response | +| systemDelete | Transaction | TransactionResponse | Deletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | +| systemUndelete | Transaction | TransactionResponse | UnDeletes a file by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | <a name="FileUpdate.proto"></a> @@ -1436,10 +1592,12 @@ ## FileUpdate.proto + Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list.<BR>If a file was created without ANY keys in the keys field, ONLY the expirationTime of the file can be changed using this call. The file contents or its keys cannot be changed. + <a name="FileUpdateTransactionBody"></a> ### FileUpdateTransactionBody - Modify some of the metadata for a file. Any null field is ignored (left unchanged). Any field that is null is left unchanged. If contents is non-null, then the file's contents will be replaced with the given bytes. This transaction must be signed by all the keys for that file. If the transaction is modifying the keys field, then it must be signed by all the keys in both the old list and the new list. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1454,10 +1612,12 @@ ## Freeze.proto + Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. + <a name="FreezeTransactionBody"></a> ### FreezeTransactionBody - Set the freezing period in which the platform will stop creating events and accepting transactions. This is used before safely shut down the platform for maintenance. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1472,6 +1632,8 @@ ## FreezeService.proto + The request and responses for freeze service. + <a name="FreezeService"></a> ### FreezeService @@ -1479,7 +1641,7 @@ | RPC | Request | Response | Comments | | --- | ------- | -------- | -------- | -| freeze | Transaction | TransactionResponse | Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse | +| freeze | Transaction | TransactionResponse | Freezes the nodes by submitting the transaction. The grpc server returns the TransactionResponse | <a name="GetByKey.proto"></a> @@ -1487,6 +1649,8 @@ ## GetByKey.proto + Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. + <a name="EntityID"></a> ### EntityID @@ -1504,7 +1668,7 @@ <a name="GetByKeyQuery"></a> ### GetByKeyQuery - Get all accounts, claims, files, and smart contract instances whose associated keys include the given Key. The given Key must not be a contractID or a ThresholdKey. This is not yet implemented in the API, but will be in the future. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1528,10 +1692,12 @@ ## GetBySolidityID.proto + Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. + <a name="GetBySolidityIDQuery"></a> ### GetBySolidityIDQuery - Get the IDs in the format used by transactions, given the ID in the format used by Solidity. If the Solidity ID is for a smart contract instance, then both the ContractID and associated AccountID will be returned. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1557,10 +1723,12 @@ ## Query.proto + A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. + <a name="Query"></a> ### Query - A single query, which is sent from the client to the node. This includes all possible queries. Each Query should not have more than 50 levels. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1589,6 +1757,8 @@ ## QueryHeader.proto + The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of GetInfo request. + <a name="QueryHeader"></a> ### QueryHeader @@ -1603,7 +1773,7 @@ <a name="ResponseType"></a> ### ResponseType - The client uses the ResponseType to request that the node send it just the answer, or both the answer and a state proof. It can also ask for just the cost for getting the answer or both. If the payment in the query fails the precheck, then the response may have some fields blank. The state proof is only available for some types of information. It is available for a Record, but not a receipt. It is available for the information in each kind of *GetInfo request. + | Enum Name | Description | | --------- | ----------- | @@ -1618,10 +1788,12 @@ ## Response.proto + A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. + <a name="Response"></a> ### Response - A single response, which is returned from the node to the client, after the client sent the node a query. This includes all responses. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1775,8 +1947,8 @@ | UNAUTHORIZED | An attempted operation was not authorized (ie - a deleteTopic for a topic with no adminKey). | | INVALID_TOPIC_MESSAGE | A ConsensusService message is empty. | | INVALID_AUTORENEW_ACCOUNT | The autoRenewAccount specified is not a valid, active account. | -| AUTORENEW_ACCOUNT_NOT_ALLOWED | | -| TOPIC_EXPIRED | | +| AUTORENEW_ACCOUNT_NOT_ALLOWED | An adminKey was not specified on the topic, so there must not be an autoRenewAccount. | +| TOPIC_EXPIRED | The topic has expired, was not automatically renewed, and is in a 7 day grace period before the topic will be<BR>deleted unrecoverably. This error response code will not be returned until autoRenew functionality is supported<BR>by HAPI. | <a name="ResponseHeader.proto"></a> @@ -1784,10 +1956,12 @@ ## ResponseHeader.proto + Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. + <a name="ResponseHeader"></a> ### ResponseHeader - Every query receives a response containing the QueryResponseHeader. Either or both of the cost and stateProof fields may be blank, if the responseType didn't ask for the cost or stateProof. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1802,6 +1976,8 @@ ## SmartContractService.proto + The request and responses for different smart contract services. + <a name="SmartContractService"></a> ### SmartContractService @@ -1809,17 +1985,17 @@ | RPC | Request | Response | Comments | | --- | ------- | -------- | -------- | -| createContract | Transaction | TransactionResponse | Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse | -| updateContract | Transaction | TransactionResponse | Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse | -| contractCallMethod | Transaction | TransactionResponse | Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse | -| getContractInfo | Query | Response | Retrieves the contract information by submitting the query. The grpc server returns the Response | -| contractCallLocalMethod | Query | Response | Calls a smart contract by submitting the query. The grpc server returns the Response | -| ContractGetBytecode | Query | Response | Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response | -| getBySolidityID | Query | Response | Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response | -| getTxRecordByContractID | Query | Response | Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response | -| deleteContract | Transaction | TransactionResponse | Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse | -| systemDelete | Transaction | TransactionResponse | Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | -| systemUndelete | Transaction | TransactionResponse | UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | +| createContract | Transaction | TransactionResponse | Creates a contract by submitting the transaction. The grpc server returns the TransactionResponse | +| updateContract | Transaction | TransactionResponse | Updates a contract with the content by submitting the transaction. The grpc server returns the TransactionResponse | +| contractCallMethod | Transaction | TransactionResponse | Calls a contract by submitting the transaction. The grpc server returns the TransactionResponse | +| getContractInfo | Query | Response | Retrieves the contract information by submitting the query. The grpc server returns the Response | +| contractCallLocalMethod | Query | Response | Calls a smart contract by submitting the query. The grpc server returns the Response | +| ContractGetBytecode | Query | Response | Retrieves the byte code of a contract by submitting the query. The grpc server returns the Response | +| getBySolidityID | Query | Response | Retrieves a contract(using Solidity ID) by submitting the query. The grpc server returns the Response | +| getTxRecordByContractID | Query | Response | Retrieves a contract(using contract ID) by submitting the query. The grpc server returns the Response | +| deleteContract | Transaction | TransactionResponse | Delete a contract instance(mark as deleted until it expires), and transfer hbars to the specified account. The grpc server returns the TransactionResponse | +| systemDelete | Transaction | TransactionResponse | Deletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | +| systemUndelete | Transaction | TransactionResponse | UnDeletes a smart contract by submitting the transaction when the account has admin privileges on the file. The grpc server returns the TransactionResponse | <a name="SystemDelete.proto"></a> @@ -1827,10 +2003,12 @@ ## SystemDelete.proto + Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. + <a name="SystemDeleteTransactionBody"></a> ### SystemDeleteTransactionBody - Delete a file or smart contract - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1845,10 +2023,12 @@ ## SystemUndelete.proto + Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. + <a name="SystemUndeleteTransactionBody"></a> ### SystemUndeleteTransactionBody - Undelete a file or smart contract that was deleted by AdminDelete - can only be done with a Hedera admin multisig. When it is deleted, it immediately disappears from the system as seen by the user, but is still stored internally until the expiration time, at which time it is truly and permanently deleted. Until that time, it can be undeleted by the Hedera admin multisig. When a smart contract is deleted, the cryptocurrency account within it continues to exist, and is not affected by the expiration time here. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1862,10 +2042,12 @@ ## Timestamp.proto + 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) + <a name="Timestamp"></a> ### Timestamp - 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) + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1888,10 +2070,12 @@ ## Transaction.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.<BR>The SignatureList field is deprecated and succeeded by SignatureMap. + <a name="Transaction"></a> ### Transaction - 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. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1907,10 +2091,12 @@ ## TransactionBody.proto + A single transaction. All transaction types are possible here. + <a name="TransactionBody"></a> ### TransactionBody - A single transaction. All transaction types are possible here. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1949,10 +2135,12 @@ ## TransactionGetFastRecord.proto + Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). + <a name="TransactionGetFastRecordQuery"></a> ### TransactionGetFastRecordQuery - Get the tx record of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -1976,10 +2164,12 @@ ## TransactionGetReceipt.proto + Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response + <a name="TransactionGetReceiptQuery"></a> ### TransactionGetReceiptQuery - Get the receipt of a transaction, given its transaction ID. Once a transaction reaches consensus, then information about whether it succeeded or failed will be available until the end of the receipt period. Before and after the receipt period, and for a transaction that was never submitted, the receipt is unknown. This query is free (the payment field is left empty). No State proof is available for this response + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -2003,10 +2193,12 @@ ## TransactionGetRecord.proto + Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. + <a name="TransactionGetRecordQuery"></a> ### TransactionGetRecordQuery - Get the record for a transaction. If the transaction requested a record, then the record lasts for one hour, and a state proof is available for it. If the transaction created an account, file, or smart contract instance, then the record will contain the ID for what it created. If the transaction called a smart contract function, then the record contains the result of that call. If the transaction was a cryptocurrency transfer, then the record includes the TransferList which gives the details of that transfer. If the transaction didn't return anything that should be in the record, then the results field will be set to nothing. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -2030,10 +2222,12 @@ ## TransactionReceipt.proto + The consensus result for a transaction, which might not be currently known, or may succeed or fail. + <a name="TransactionReceipt"></a> ### TransactionReceipt - The consensus result for a transaction, which might not be currently known, or may succeed or fail. + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -2043,8 +2237,8 @@ | contractID | [ContractID](#ContractID) | The contract ID, if a new smart contract instance was created | | | exchangeRate | [ExchangeRateSet](#ExchangeRateSet) | exchange rate set of Hbar to cents (USD) | | | topicID | [TopicID](#TopicID) | TopicID of a newly created consensus service topic | | -| topicSequenceNumber | | | | -| topicRunningHash | | | | +| topicSequenceNumber | | Updated sequence number for a consensus service topic. The result of a ConsensusSubmitMessage. | | +| topicRunningHash | | Updated running hash for a consensus service topic. The result of a ConsensusSubmitMessage. | | <a name="TransactionRecord.proto"></a> @@ -2052,10 +2246,12 @@ ## TransactionRecord.proto + Response when the client sends the node TransactionGetRecordResponse + <a name="TransactionRecord"></a> ### TransactionRecord - Response when the client sends the node TransactionGetRecordResponse + | Field | Type | Description | | | ----- | ---- | ----------- | - | @@ -2076,10 +2272,12 @@ ## TransactionResponse.proto + When the client sends the node a transaction of any kind, the node replies with this, which simply says that the transaction passed the precheck (so the node will submit it to the network) or it failed (so it won't). If the fee offered was insufficient, this will also contain the amount of the required fee. To learn the consensus result, the client should later obtain a receipt (free), or can buy a more detailed record (not free). + <a name="TransactionResponse"></a> ### TransactionResponse - When the client sends the node a transaction of any kind, the node replies with this, which simply says that the transaction passed the precheck (so the node will submit it to the network) or it failed (so it won't). If the fee offered was insufficient, this will also contain the amount of the required fee. To learn the consensus result, the client should later obtain a receipt (free), or can buy a more detailed record (not free). + | Field | Type | Description | | | ----- | ---- | ----------- | - |