From d930bc8478f3069eb7d30713ff481b86695769fa Mon Sep 17 00:00:00 2001 From: Greg Scullard Date: Wed, 15 Jan 2020 15:53:15 +0100 Subject: [PATCH] fixes markdown doc --- docgenerator/proto2html.jar | Bin 24635 -> 24618 bytes docs/NotNestedDoc.md | 190 ++++++++++++++++++++++++++++-------- 2 files changed, 151 insertions(+), 39 deletions(-) diff --git a/docgenerator/proto2html.jar b/docgenerator/proto2html.jar index 5a2849e40ad5d68782e78fc83c6fe63d5a27200e..f64472d319efbe875849ab244ffc2e7fc06ba0a3 100644 GIT binary patch delta 4158 zcmZA4WmME%w*YV$x}*jeg^@-&hX#=nX+&zshmMi%{0qWRl0zdQEg&ICNK42tgo>0P z2t!E95CT$Ho^{uK-*wMAYyZwUAI>@-_Bwm*j$ZugUVKUeZ303t9w{j)UO+?|5B*V?}VIAo%oOc_7jR zpqx;Y4YL}sowC*q9hTRF6C=7WHlAlFHGZdova7?yWPt5 zYGVBK0137U$nXweH+Fpym_1jJUvTEsUC_>|)DuCl&!R6>263xAPbTSSfm6dqH6>lZcDxJuej*l97bnoSfb0O>dN97-&$hixh8F(iPbUxX8u{jS(5qn{pkztfty$~*0h z81%HmtmdONjtX@#pkzGub@-g&?)vLe2Il;>zSLhB_$qn$CMAN2YIf4r$aje~)^bdT z{)(s@R!%}Dpj7saLgN+laL!LwiZyf^Q7oXPEypdD7Xmi5yZyS5Re-pI8OgClsF1Aw zf)1yHvcwl)JjR>!%;P~TFZCLKDP&g{Nv)q!>aPp$`=;?nYx&L__yN9NgI*#!{bl-*ZhG;QSNO}7bNEMOtSZYJ6MN^x>hGq{%v?m;lxK^Gr zzm#ve!?iIBCw3w>qaQAIYreDP9uK%0bAKjxkVCkPL(fe;Vx zKgszwi+(^K08=LOPv}iqu5M}0(wL~zz+5B=Yc+Y*aO7k-kc$haU87k;D>ody!jtd8 zDA2VeAHG{U8LMX_SFovyU_caX9<@(g2AZE2e9u5Q_2zbik-p=FhaCmK&MzZkm9DOi zrSU5FW1@&7%@+B&6GN0+-<6mMjnA8x=hV(-*;9dmg7n;%8JI-mYk_@=W}1OAuJtT|GYKP9Gjj?oM}4ohwdIZ^|@=< zeDqcXeDedukNXc(%!uALS`@oa?FG+IXK_`rHy7&;-fgCURV2M#b|4IEJZ+BZ0^x-0 z?!G%)rt>leUg2S%0}N>`UyZ2hSM<_RPF`SWPVSK=P1!syj3*;4hKNZNK7 zX0xX`)Gc~sS$28eR@@!4Y~tT68=AZyJjaC{eI%jDFh&~VMfs6|vKC`50%5r4W%xj> z+P*xYX%z%x9&i=@f`Umu%9uoJ&X{Sb<0XwjhTud4J{y0yOuTPx1Pk@ES0oQ&0tZ$A z1SxC%Ze^ZWlo(N|&dOLNzwk=>sL$msZ8!a=LOAPJ<=_|e#qMjCr0~vS6?MHIZr=^7 zOexys=8QxL*3@~7EWK$R!1OQL;~lJxaU3chvRTl2mcX?aZ|^sn zslia5BVJ#n))Q}~nB+$p!(GWX9b(8wDQyA+)u#JP$O+nM!d&bVMx>;cyLtPn9pw)| zxFIZK#`c+FOvoQ-*}$iduht%g#&s!E6WoX(qK{&^M1_i z#O5dQ_a7n$!jIY#r=6w4J}NXuODleicfQ2PgfJB>$Q;)P_1udXqKAY;1I@ju2T(iP zHCkcPi{u>xtQOnygSN&Qpjc$bX6Wz>EJm1OA^gBu#)}oD^gb|eMJ7@zxg%()%VqF> z^cl1Ay_MONQkiGU_uV(VXtKTH-dY9aPE2k8RHlu!Wk-teoiWgzW^J>6ibXVM`9FRi zn=MM!Rp&r% zh5M&H*8#_0)3Dbh94De8F&vSVwPZ6dhEHOfMvIi~f%j^hT7ScN48-$L8cu08IPNE2Z{@I^u$S=#wnf02}_@u zTCVbR?5!Zj7CQ&OFnJPER0lOQyCEU#=%E>E`n@lKY%vsDvjl^?bPK|?zdP)>WW1VQrS;QS!*F7W8C_+;IKUMPPKXgL6=!uSh@7AM)aq+xSRhM9zBM&?0w@*R}f z67H?M1`;j~+RdbLPJOVlhkj4;TgQ?k+!8A!T*_swYhb%3Y51Op9GR8^%u7JVgi|h& zm4vx_w&Xv|9_Zz0BlS|X^Eb84Lh8;EbXo50e34r&Pgzah@+~hqbswpYcKX-161m&mErq6KKL$=H@GP<-fVvJ2dIcR0D7%zf_Y*gIynFu87FA+_tM z&&IgBSJ(_tdynXqeqyZg8-Oyn(@*MFA`CMXh#Qm1E_Ax{4>yyz1u!_8X}ed%xuJIY z&RPK|Im5Oh8Ay2exsY@dnzkxMF9kebxvVVd*_79+`O!(XKJO6r6yQe2%f!MIR%vs8 zQQMMydmeO(4E+&2*+}2;k=trbWv*0X}F$s&k_1EYWfTH8xsl!?dbE@6qlYH!T=dsJ|S57V0B|rgX_gV%sQgn=KHP8i?-RkDS(;zpraN zt`n?O%bCc6h|WJDCR*1Ja42D)xLEtl9pI~!yx&HT`_AWY=M%3E71q*;na`D4;1lR{ z_$h}cu;3Rg9HYgZ_?v1i zUJS$Sc6n_DD6|Dz)ur7Zz3pgYENi{6)TB5>bxsh-!x5u|dmOCOZ!@a|S%Ze4!WXkz zU72Ku&Zja(WDj8Fv8mP30*)|P}OIopEK zJ)%FOMl{7bCQR+LD=F`=nwrbJ?jL3Cwq@}uHd=Fd%m@QlCRoS#C)g_w|y>=4^-JYZ7Ji2Y{S%Xkz!Auk~W7$4Qi2kE*rpg z9qogFc}NSjeT%qjnGaaQLa`A`XV|xE{;9t*e~V%14>an{?!*X1Cv4Y;8CT5R{pg&oHR;lz zqPUhtuEf`(cra;)7vx-X1v~6Lu>OlQS8#=J=?IkpjIZ!c{Nc0wK(ja?5tPy#@dDeX zl{kT8xk}i;Nm_q6DLY}6i2<+-7u1#LmD`U~nmD2k?HGjP-W{#@X1)9&DBB13iE3IU zbVewQL%5ZanpU~SonEbLa1GCGJ=&%oHTnUKnfa-IQwIaKf=lL!@$e$3{!<50nv!%) zV1YKFzkM-k-0Y@(MuFj?H#~&P-0%#pa6>m-{RSd)qZ=&Doo?ti_q##X!uf_03&ai7 zmL7j;0xYHQNpnI)3~m}GRF{SwGU-SHCRi6 qHu?WulG;e&i=vclEI|886IosfR>CbE^eWgOTce!7+|MC1gPvSRd`nHEJ zq%aYkaISTG<)bIlmwaR;`b$Hh=>oFn)y2)?_s9>U*pK%Y988Vv9I4 zFb-2_y-&s|oK84}evmF4MQ4HL6WmLea@oUGWJA`ite(Fl$t>3(WijgB<9diFW#B;zgEENkSRR6j#);*_VwFmzALdWGq0 zbQieH;Lr0s(p1#)Rl`$X4-tfTuXN-rOR2{svqwrMZx7ot4{DkDX!cf-zxDEo2Sk0c zv76vMNdtGX@@E(D%)}}imgmYKi&>eU6UX-pJUz{O1Vfi0E1Uo*O_SG*G12M{&B(aRRJm!_UB^n30Bm> zi)YYq^)kcg?UNcWH|g5cJki!iLRJt><4QElnfB<=m$y*tr~^>1a9rbW5VzgBu62EV zQd8K7dmS_-CZJq@AmPdS0jVlq2;nnUDzfd*=5?FRuOud^f$EgawFkq43Uyz7A2y#M z@|#MvBC_chOIRoQaP4PcLlfV}zlTee;%Jia=~TKlKl{-_T*t-L&>*zk*mq#6(*nJ_ zb8_5Vr_j$a&>1cHx4bI<-{IKZAr{zS5VdNq@>iRbbd)#MYtno<}o> z8l_sejoniEIf*Ph(P0(?9NTC`ID$eFGCt-_w+h%3mcRN$Mk{Q`lQY}2Fdmt~2*F$A zaK}l~xuoPkj!xYsr!W&~E;YmoxuSm-d*a~wSGy?mCCLFEe@$oA$F>%eU({_>voU{2 zys34wsE3Ig**f*vd03er?=HKSF**cvMs&nfyTI9=hR)X)p;bOZ-&ROHjR3^z19{VH z0~w2WVPppCiPI}s`Z`0yp3a1{@-vcl1ZuPtWMmem4tJZ0B#`)&F8(+7&4EpFIWpTsx@#t`5vy#*x&F9*SCaYpWY@Vp!ZZm5tPTXp@ zOBQM6IbClSDFJdn@h~&;Ewyj%aTe?^ti7`NQ3H=sG^S*@Li2nYLtcl7$0)xe6}azS z+3DK+$L2UUZ(;964eK14?s&JC>d?9qNB2nsQa^|+A zBglh6TslroQ@Pl%F5$UDmllq3WO+3|*Ojf#i*P?ImX;>?COu1xRvmH~?(eLR_H}qJ~DLn+_2AmU{gw^fC6pu61T!1I?iZU-eBYKMJA7G;QLiWty z&L8gwKlL(q33UAoU9T9-pBoQ3tnsD{-Y@LdivL(+Z|>U)sBDHpg6esSvlZk9?tk zQVja<4w8`^O#73__%d`>EXB;7w+9igjMz#dqSrLt!V>6vO0PMCd}CHsJ=1@EGtvUI z`Q`ZcXV%%oo})E>@SVwao!#q7l%&@t?itKG*(?3Pwi>CbT2={cl1`NuGh#JKsYULz zbPcV@9b6}*K6Ap`(;ZE>4%ZXm{FAReBte2NG>=;ylV4BOzJ}PSQPvKl^;L21-0iAD zY>B-~V)=@C3PnfID?XDYO?gSR zdDx`)&9QiBTqz;z1%vPt_par-qg2$_|2yg&4_JulD7TQ0NEDo*^!LZFbtEZhRKozP z?M^5n8Z#H7zPG&$ZDfgsEiG%9Lg`7eTe3VC-#K~O=Xq_Tso3diwAxpEO*Px8_w~|P z;kwHubtum*1>NF+s3V!m?tYM-K8=+Z-`iMYvTWLURshF*H z1Nl0Qg&OOU$3=;9%idg~S=>KDmYW7hE2|Krlf=@lYOzCQ4+NJU830 zj=(6{B(k29CfbvXDo0Tahg4>L6eVuPbMiN9YwynAmnzTuaUNK?nj9Ixf{X47d-8h|P_kQ?-O#VGEX*Z;1aZnXMUy(v%1 zs6OEEOp^f;7%zY(dES6mpy+X9!W=N`=P}^lG$gABdGuO?toz}Q=+npsoE61oE|Flw znBR#yG3k$IdkmSDi*97D7$jS|1P5}M$#l9&eZVU`moBm;ibkC~-jHjDHZdp06=TE_ z+0XWy=zSj3*MR=EHGk$OeKw($J82oSW`fI=yu`)iu1GBOoGV*512-m1^Su%sU9$~M zTv-97OMT{V-V%hv*ku^A^u_|`^0PM}AN>{t7XwkewUy8ZsI`@57?D^PRR`mh zoegp%jutwivp7Eeypc7suHj5ohfBzgoJ;GUgET4{BGqJl;p=LnCU&Gr!6AD(pVP*4 zzXwoF8c=b`6_c|5VFOIloq^z5Fr}G5XUt;Uw%=#eCH$y4lBiJs_JfI437Y{eX`(!yMc- zd9ey||E@iW6!bO_ew2Os*#IPS1bO`;dFQ$2Ye|XbFSGqWk30_HN{|3>Q+KtfVUDDs zD#RZ=SrISJ&zT45wOwa;Uu?wAN*N|xwxI#Om+I*(QZKk1z@WX;*--miLdc*28G2vi zE!9Ok+9J%()0y%M3V*M>@dU^50uh!aM)%R+sc0nqra;*C!`XN9xj=1x`#AABexUw6 zd!(x8%5hS)Piw5dbX_r6c+uT49t``$q6<=;w8OKkGh=okd2W)#z913rO<2!5usEc! zG;CU-aIPw3^o|DdLNd|zSj34hgPTarw_+s%ZCRdNvNegq&y~gLdONmE@i|!gAF5v?iBfF^Id2+rf>-r%rHuU2k(D^%g ziFy=_L&XQDtN6~3E$uDOZO$h}mtU_@vaa%I2OeOv%5Mxrg$BHj^4ksYV*X(mL?AJX z4pfvYi%jyp4qY`-@LfZl7K|^w9KPy(ZsES}jZJ6IzJDvWih8c=APy;c5$Z|lwS{2K z?BkMogkf@oFYMR_Pce6mmD~aDub1f%3G!4@)$RoAbcKE#nW}9Y~1!aPb)25;r1l7%O`OO@sq37>Xiee z1=jc=nwI%Au65)H=5yaDvRp5W_VeqjbE(bI(^9STN{tPAY1nA}p~kA}gb6n~<+@el zSTZDn+VyuPEZ#1g#uKJXlO~y9*E>9+b)LR41rJL+hch3>K-Z}szvJ17)}5hzSwUM7 zjq#_#(M{Ix+jA&-8@$7VGrdu$@dIn_-e{IUyIo57RRi-?V_sJ$X<*&_H8UHIrd0p^ zYtWQ0)B40}i~)Ur9)@v0C6CqND@zC>LD+}2r~l@hj66A<{HycPsR`47bqGCJmV4{K zvWsSTkVTDP{3<{c;d7*zu7@r&70ZZX3%~Vo3h-77%O#LpNc)ySXW?#?qMdZu9>iZW_6jF58)l zu-<>)f`!G0^}lPLGwpzxJ?*6x7;wq=FFmt@02IOhQax)ZfLHQgT5Bx@h?f4B64)@| J_nF>Z@*j}0yB`1m diff --git a/docs/NotNestedDoc.md b/docs/NotNestedDoc.md index 0999c63f..f9751faf 100644 --- a/docs/NotNestedDoc.md +++ b/docs/NotNestedDoc.md @@ -239,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. + ### AccountID @@ -586,6 +588,8 @@ ## ConsensusCreateTopic.proto + See [ConsensusService.createTopic()](#proto.ConsensusService) + ### ConsensusCreateTopicTransactionBody @@ -605,6 +609,8 @@ ## ConsensusDeleteTopic.proto + See [ConsensusService.deleteTopic()](#proto.ConsensusService) + ### ConsensusDeleteTopicTransactionBody @@ -620,6 +626,8 @@ ## ConsensusGetTopicInfo.proto + See [ConsensusService.getTopicInfo()](#proto.ConsensusService) + ### ConsensusGetTopicInfoQuery @@ -648,6 +656,8 @@ ## ConsensusService.proto + The Consensus Service provides the ability for Hedera Hashgraph to provide aBFT consensus as to the order and
validity of messages submitted to a topic, as well as a consensus timestamp for those messages.
Automatic renewal can be configured via an autoRenewAccount.
Any time an autoRenewAccount is added to a topic, that createTopic/updateTopic transaction must be signed by
the autoRenewAccount.
The autoRenewPeriod on an account must currently be set a value in createTopic between MIN_AUTORENEW_PERIOD (6999999
seconds) and MAX_AUTORENEW_PERIOD (8000001 seconds). During creation this sets the initial expirationTime of the
topic (see more below).
If no adminKey is on a topic, there may not be an autoRenewAccount on the topic, deleteTopic is not allowed,
and the only change allowed via an updateTopic is to extend the expirationTime.
If an adminKey is on a topic, every updateTopic and deleteTopic transaction must be signed by the adminKey, except
for updateTopics which only extend the topic's expirationTime (no adminKey authorization required).
If an updateTopic modifies the adminKey of a topic, the transaction signatures on the updateTopic must fulfill both
the pre-update and post-update adminKey signature requirements.
Mirrornet ConsensusService may be used to subscribe to changes on the topic, including changes to the topic
definition and the consensus ordering and timestamp of submitted messages.
Until autoRenew functionality is supported by HAPI, the topic will not expire, the autoRenewAccount will not be
charged, and the topic will not automatically be deleted.
Once autoRenew functionality is supported by HAPI:
1. Once the expirationTime is encountered, if an autoRenewAccount is configured on the topic, the account will be
charged automatically at the expirationTime, to extend the expirationTime of the topic up to the topic's
autoRenewPeriod (or as much extension as the account's balance will supply).
2. If the topic expires and is not automatically renewed, the topic will enter the EXPIRED state. All transactions
on the topic will fail with TOPIC_EXPIRED, except an updateTopic() call that modifies only the expirationTime.
getTopicInfo() will succeed. This state will be available for a AUTORENEW_GRACE_PERIOD grace period (7 days).
3. After the grace period, if the topic's expirationTime is not extended, the topic will be automatically
deleted and no transactions or queries on the topic will succeed after that point. + ### ConsensusService @@ -655,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.
If an autoRenewAccount is specified, that account must also sign this transaction.
If an adminKey is specified, the adminKey must sign the transaction.
On success, the resulting TransactionReceipt contains the newly created TopicId.
Request is [ConsensusCreateTopicTransactionBody](#proto.ConsensusCreateTopicTransactionBody) | +| updateTopic | Transaction | TransactionResponse | Update a topic.
If there is no adminKey, the only authorized update (available to anyone) is to extend the expirationTime.
Otherwise transaction must be signed by the adminKey.
If an adminKey is updated, the transaction must be signed by the pre-update adminKey and post-update adminKey.
If a new autoRenewAccount is specified (not just being removed), that account must also sign the transaction.
Request is [ConsensusUpdateTopicTransactionBody](#proto.ConsensusUpdateTopicTransactionBody) | +| deleteTopic | Transaction | TransactionResponse | Delete a topic. No more transactions or queries on the topic (via HAPI) will succeed.
If an adminKey is set, this transaction must be signed by that key.
If there is no adminKey, this transaction will fail UNAUTHORIZED.
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.
Deleted accounts will not be returned.
Request is [ConsensusGetTopicInfoQuery](#proto.ConsensusGetTopicInfoQuery)
Response is [ConsensusGetTopicInfoResponse](#proto.ConsensusGetTopicInfoResponse) | +| submitMessage | Transaction | TransactionResponse | Submit a message for consensus.
Valid and authorized messages on valid topics will be ordered by the consensus service, gossipped to the
mirror net, and published (in order) to all subscribers (from the mirror net) on this topic.
The submitKey (if any) must sign this transaction.
On success, the resulting TransactionReceipt contains the topic's updated topicSequenceNumber and
topicRunningHash.
Request is [ConsensusSubmitMessageTransactionBody](#proto.ConsensusSubmitMessageTransactionBody) | @@ -683,6 +693,8 @@ ## ConsensusTopicInfo.proto + Current state of a topic. + ### ConsensusTopicInfo @@ -705,6 +717,8 @@ ## ConsensusUpdateTopic.proto + All fields left null will not be updated.
See [ConsensusService.updateTopic()](#proto.ConsensusService) + ### ConsensusUpdateTopicTransactionBody @@ -726,6 +740,8 @@ ## 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.
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. + ### ContractCallTransactionBody @@ -744,6 +760,8 @@ ## ContractCallLocal.proto + The log information for an event returned by a smart contract function call. One function call may return several such events. + ### ContractCallLocalQuery @@ -802,6 +820,8 @@ ## 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.
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.
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.
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.
An entity (account, file, or smart contract instance) must be created in a particular realm. If the realmID is left null, then a new realm will be created with the given admin key. If a new realm has a null adminKey, then anyone can create/modify/delete entities in that realm. But if an admin key is given, then any transaction to create/modify/delete an entity in that realm must be signed by that key, though anyone can still call functions on smart contract instances that exist in that realm. A realm ceases to exist when everything within it has expired and no longer exists.
The current API ignores shardID, realmID, and newRealmAdminKey, and creates everything in shard 0 and realm 0, with a null key. Future versions of the API will support multiple realms and multiple shards.
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. + ### ContractCreateTransactionBody @@ -827,6 +847,8 @@ ## 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. + ### ContractDeleteTransactionBody @@ -845,6 +867,8 @@ ## ContractGetBytecode.proto + Get the bytecode for a smart contract instance + ### ContractGetBytecodeQuery @@ -872,6 +896,8 @@ ## 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. + ### ContractGetInfoQuery @@ -917,6 +943,8 @@ ## 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. + ### ContractGetRecordsQuery @@ -945,6 +973,8 @@ ## 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. + ### ContractUpdateTransactionBody @@ -966,6 +996,8 @@ ## 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. + ### Claim @@ -994,6 +1026,8 @@ ## 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.
An entity (account, file, or smart contract instance) must be created in a particular realm. If the realmID is left null, then a new realm will be created with the given admin key. If a new realm has a null adminKey, then anyone can create/modify/delete entities in that realm. But if an admin key is given, then any transaction to create/modify/delete an entity in that realm must be signed by that key, though anyone can still call functions on smart contract instances that exist in that realm. A realm ceases to exist when everything within it has expired and no longer exists.
The current API ignores shardID, realmID, and newRealmAdminKey, and creates everything in shard 0 and realm 0, with a null key. Future versions of the API will support multiple realms and multiple shards. + ### CryptoCreateTransactionBody @@ -1018,6 +1052,8 @@ ## 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. + ### CryptoDeleteTransactionBody @@ -1034,6 +1070,8 @@ ## 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. + ### CryptoDeleteClaimTransactionBody @@ -1050,6 +1088,8 @@ ## 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. + ### CryptoGetAccountBalanceQuery @@ -1080,6 +1120,8 @@ ## 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. + ### CryptoGetAccountRecordsQuery @@ -1108,6 +1150,8 @@ ## CryptoGetClaim.proto + Get a single claim attached to an account, or return null if it does not exist. + ### CryptoGetClaimQuery @@ -1136,6 +1180,8 @@ ## CryptoGetInfo.proto + Get all the information about an account, including the balance. This does not get the list of account records. + ### CryptoGetInfoQuery @@ -1185,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. + ### AllProxyStakers @@ -1234,6 +1282,8 @@ ## CryptoService.proto + The request and responses for different crypto services. + ### CryptoService @@ -1241,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. | @@ -1262,6 +1312,8 @@ ## CryptoTransfer.proto + An account, and the amount that it sends or receives during a cryptocurrency transfer. + ### AccountAmount @@ -1298,6 +1350,8 @@ ## 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. + ### CryptoUpdateTransactionBody @@ -1327,6 +1381,8 @@ ## 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) + ### Duration @@ -1342,6 +1398,8 @@ ## ExchangeRate.proto + Values from these proto denotes habr and cents(USD) conversion + ### ExchangeRate @@ -1370,6 +1428,8 @@ ## 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. + ### FileAppendTransactionBody @@ -1386,6 +1446,8 @@ ## 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.
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.
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.
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.
An entity (account, file, or smart contract instance) must be created in a particular realm. If the realmID is left null, then a new realm will be created with the given admin key. If a new realm has a null adminKey, then anyone can create/modify/delete entities in that realm. But if an admin key is given, then any transaction to create/modify/delete an entity in that realm must be signed by that key, though anyone can still call functions on smart contract instances that exist in that realm. A realm ceases to exist when everything within it has expired and no longer exists.
The current API ignores shardID, realmID, and newRealmAdminKey, and creates everything in shard 0 and realm 0, with a null key. Future versions of the API will support multiple realms and multiple shards. + ### FileCreateTransactionBody @@ -1406,6 +1468,8 @@ ## 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). + ### FileDeleteTransactionBody @@ -1421,6 +1485,8 @@ ## FileGetContents.proto + Get the contents of a file. The content field is empty (no bytes) if the file is empty. + ### FileGetContentsQuery @@ -1459,6 +1525,8 @@ ## 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. + ### FileGetInfoQuery @@ -1500,6 +1568,8 @@ ## FileService.proto + The request and responses for different file services. + ### FileService @@ -1507,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 | @@ -1522,6 +1592,8 @@ ## 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.
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. + ### FileUpdateTransactionBody @@ -1540,6 +1612,8 @@ ## 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. + ### FreezeTransactionBody @@ -1558,6 +1632,8 @@ ## FreezeService.proto + The request and responses for freeze service. + ### FreezeService @@ -1565,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 | @@ -1573,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. + ### EntityID @@ -1614,6 +1692,8 @@ ## 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. + ### GetBySolidityIDQuery @@ -1643,6 +1723,8 @@ ## 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. + ### Query @@ -1675,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. + ### QueryHeader @@ -1704,6 +1788,8 @@ ## 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. + ### Response @@ -1870,6 +1956,8 @@ ## 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. + ### ResponseHeader @@ -1888,6 +1976,8 @@ ## SmartContractService.proto + The request and responses for different smart contract services. + ### SmartContractService @@ -1895,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 | @@ -1913,6 +2003,8 @@ ## 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. + ### SystemDeleteTransactionBody @@ -1931,6 +2023,8 @@ ## 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. + ### SystemUndeleteTransactionBody @@ -1948,6 +2042,8 @@ ## 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) + ### Timestamp @@ -1974,6 +2070,8 @@ ## 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.
The SignatureList field is deprecated and succeeded by SignatureMap. + ### Transaction @@ -1993,6 +2091,8 @@ ## TransactionBody.proto + A single transaction. All transaction types are possible here. + ### TransactionBody @@ -2035,6 +2135,8 @@ ## 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). + ### TransactionGetFastRecordQuery @@ -2062,6 +2164,8 @@ ## 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 + ### TransactionGetReceiptQuery @@ -2089,6 +2193,8 @@ ## 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. + ### TransactionGetRecordQuery @@ -2116,6 +2222,8 @@ ## TransactionReceipt.proto + The consensus result for a transaction, which might not be currently known, or may succeed or fail. + ### TransactionReceipt @@ -2138,6 +2246,8 @@ ## TransactionRecord.proto + Response when the client sends the node TransactionGetRecordResponse + ### TransactionRecord @@ -2162,6 +2272,8 @@ ## 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). + ### TransactionResponse